Modern web applications rarely load only their own code. Analytics platforms, chat widgets, advertising networks, payment processors, and customer support tools all contribute JavaScript that runs in the user’s browser with the same level of trust as the application’s own code. That trust is often not warranted.
Each third-party script included in a web application represents a dependency on the security practices of the organisation that controls it. A compromised CDN, a hijacked analytics account, or a malicious update to a widely-used library can turn a legitimate-looking web page into a credential harvester or a data exfiltration endpoint.
The Scope of Third-Party Script Access
JavaScript running in a browser has access to the entire DOM, including form fields, input values, and page content. It can read cookies that are not flagged as HttpOnly. It can capture keystrokes, intercept form submissions, modify page content, and make requests to external servers. A third-party script has all of these capabilities unless they are explicitly restricted.
Content Security Policy (CSP) is the primary browser-level control for limiting what third-party scripts can do. A strict CSP restricts which origins can load scripts, which origins scripts can make requests to, and prevents inline script execution. Implementing a meaningful CSP requires significant effort in applications that use many third-party tools but provides genuine risk reduction.
Magecart and Digital Skimming
Magecart-style attacks compromise third-party scripts to inject card skimming code into payment pages. When a user enters their card details, the skimming code captures them and transmits them to an attacker-controlled server before the legitimate payment processing continues. The user sees a normal transaction. The merchant’s payment page looks normal. The compromise is invisible to both.
These attacks target the third-party ecosystem rather than the merchant’s own infrastructure. The merchant may have excellent security on their own codebase but include a script from a less well-secured analytics or tag management provider. The attacker compromises the provider, not the merchant, and reaches thousands of merchant sites through a single compromise.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
“Third-party JavaScript is one of the most underappreciated web application risks we encounter. An organisation might have excellent security on its own code but run six or seven third-party scripts on every page, each with broad DOM access. A single compromised script can harvest everything a user types on your site, and you may not find out until a researcher tells you.”
Testing and Monitoring
Web application penetration testing includes review of third-party script inclusions, assessment of the CSP implementation, and evaluation of whether the application’s third-party dependencies introduce vulnerabilities. This is distinct from SCA because it focuses on runtime behaviour rather than static dependency versions.
Subresource Integrity (SRI) attributes allow browsers to verify that scripts loaded from external sources have not been modified. Including a cryptographic hash of the expected script content means the browser will refuse to execute a modified version. SRI is straightforward to implement for scripts loaded from CDNs with stable content.
Reducing Third-Party Risk
Vulnerability scanning services that include web application assessment can identify third-party scripts without integrity verification, absent or weak CSP headers, and scripts loaded from domains with poor security reputations.
Regular audits of which third-party scripts are loaded, from which domains, and with what permissions reduce the attack surface over time. Scripts that were added for features that are no longer in use are a common finding. Each unnecessary script removed is an attack vector eliminated.
