The surface area of website and web application attacks keeps growing. One reason for this is the prevalence of third-party code. When businesses build web apps, they use code from many sources, including both commercial and open-source projects, often created and maintained by both professional and amateur developers.
Web application creators take advantage of third-party code because it allows them to build their websites and apps quickly. For example, companies are likely to add a third-party chat widget to their site, instead of building one from scratch.
But third-party code can leave websites vulnerable. Consider the July 2018 Magecart attack on Ticketmaster. In this data breach, hackers were able to gain access to sensitive customer information on Ticketmaster's website by compromising a third-party script used to provide chatbot functionality.
The challenge is that this third-party functionality runs directly on the customer's browser, and the browser is built to simply render the code sent down from a web server. It assumes that all code, whether first-party or third-party, is good.
If JavaScript reads the information that a visitor enters into a credit card field, for example, the browser assumes the request is legitimate and complies—that is, unless security teams put stringent security measures in place to actively prevent this.
Automatic, assumed trust is how companies like Ticketmaster got into this mess. To fix this problem in browser security, companies need to start assuming that they can't trust anyone or anything. Since using third-party code is essential to today's development efforts, here are four tips for revamping security.
Adopt a zero-trust approach to third-party code
Giving third-party code default access to everything on your website can get you into trouble—but it is how browsers work. You need to implement control. When adding third-party code, you need to assume that it's not a matter of if the code gets hacked, but when.
Your team should whitelist only the JavaScript that requires access to the sensitive information. Take inventory of all third-party code and block it from accessing any other information on your site.
Then go through and add back-access permissions only where necessary. Does a chat widget need to access visitors' credentials when they log into the website? Probably not. Keep access restricted only to code that actually needs it.
Embed your third-party code in iframes
An iframe is an HTML element that allows developers to embed external content (such as videos, maps, and shopping cart checkouts) into an isolated environment in a browser window. Third-party code embedded in an iframe will be separate from the first-party code your team adds to the rest of your website.
Anything embedded inside an iframe can't access the content on the main webpage.
Some third-party code requires access to information on your site to perform specific tasks, so implementing iframes can limit the types of outside code you can use. For example, if you block code in an iframe from seeing the information input into web forms at checkout, you can't use third-party code for retargeting ads later if customers abandon their shopping carts.
Put third-party code only where it's absolutely necessary
Don't put yourself in harm's way unless you need to. We know there is code we can't avoid—for example, your team might want Google Analytics everywhere. But you need to keep in mind that this comes with risk.
Keep third-party code restricted to where you really need it, and don't include it in sensitive sections on your website. For example, many banks don't add third-party scripts on or behind their login page. They might have external code on their homepage, but once a customer logs in, everything is built with first-party code to keep customer information as safe as possible.
Implement a content security policy
Web teams can build content security policies (CSPs) that create blanket rules that dictate which domains can run code and send data on sensitive pages. Unfortunately, this approach requires ongoing maintenance, so it's a heavier lift for IT teams. But ultimately, it's an effective way to prevent malicious hackers from gaining access to visitors' sensitive information.
You need third-party code to run your online business. But you can't feasibly ensure that all code is secure. Too many developers from too many companies are involved with creating it. Even if it's safe when you add it to your web app, there's no guarantee the original vendor won't get attacked or inadvertently add vulnerable code sometime down the line.
The only way to ensure that your customer data stays secure is to assume that all third-party code can and will become a vulnerability, and then protect your web app from it. No matter how often you check for vulnerabilities, you can't protect against bad third-party code.
Don't assume any code is safe. Zero trust is how you ensure that only approved code can access sensitive information.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
