The Hidden Risk of Third-Party JavaScript on Your Website

The average website loads scripts from 15 to 30 different third-party domains: analytics, advertising, chat widgets, fonts, A/B testing, consent management, social media embeds, and payment processors. Each script runs with full access to the page — it can read every form input, access cookies, modify the DOM, and make network requests to any destination. You're granting every third-party vendor the same level of access as your own application code, and one compromised vendor compromises every site that loads their script.

The Access Problem

When you add a <script src="https://vendor.com/widget.js"> tag to your page, that script executes with the full privileges of your origin. It can:

• Read and modify the DOM: Access every element on the page, including form inputs, hidden fields, and dynamically loaded content.
• Access cookies: Read any cookie not protected by the HttpOnly flag, including session tokens.
• Make network requests: Send data to any server, using fetch, XMLHttpRequest, navigator.sendBeacon, or even dynamic image tags.
• Modify page behaviour: Override event handlers, intercept form submissions, redirect users, and inject new content.
• Access browser APIs: Use geolocation, camera, clipboard, and storage APIs (subject to permissions policy).

This isn't a vulnerability — it's how browsers work. The browser doesn't distinguish between your first-party JavaScript and a third-party script. Both have identical capabilities once loaded.

Real-World Supply Chain Attacks

The Magecart attack campaigns demonstrate the real-world impact. These groups compromise third-party scripts used by e-commerce sites to inject credit card skimmers. The compromised script captures payment form data as users enter it and exfiltrates it to attacker-controlled servers.

Notable incidents include:

• British Airways (2018): A modified script on BA's own site captured 380,000 payment card details. The attacker compromised a supply chain dependency that BA loaded.
• Ticketmaster (2018): A compromised customer support chat widget (Inbenta) injected a card skimmer on payment pages.
• Feedify (2018): The push notification service was compromised, injecting a Magecart skimmer into every site using their widget.

In each case, the attacked company's own code was unmodified. The compromise came through a trusted third-party script that changed its behaviour.

Subresource Integrity: Pinning Script Content

Subresource Integrity (SRI) adds a cryptographic hash to script and link tags. The browser calculates the hash of the downloaded file and compares it to the expected hash. If they don't match, the script is blocked.

<script
  src="https://cdn.example.com/library.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"
></script>

SRI guarantees that the file you load is exactly the file you intended. If the CDN is compromised and the file is modified, the integrity check fails and the script doesn't execute. This is an effective defence against CDN compromise and transit modification.

The limitation is that SRI breaks when the vendor legitimately updates their script. Pinning a hash means you must manually update the hash whenever the vendor releases a new version. This creates an operational burden that discourages adoption — which is why fewer than 5% of sites use SRI despite wide browser support.

Content Security Policy for Third-Party Control

CSP provides fine-grained control over what scripts can do. A well-configured CSP can:

• Restrict script sources: Only allow scripts from explicitly whitelisted domains, preventing any injected script tag from loading from an unauthorised source.
• Block inline scripts: Prevent injected inline JavaScript from executing, even if an attacker can modify the DOM.
• Restrict network destinations: The connect-src directive limits where scripts can send data, blocking exfiltration to attacker-controlled servers even if a script is compromised.
• Sandbox frames: The sandbox directive restricts the capabilities of embedded iframes, limiting what third-party widgets can do.

The combination of SRI (verifying script content) and CSP (limiting script capabilities) provides defence-in-depth against third-party script compromise.

The Vendor Assessment Gap

Most organisations have procurement processes for SaaS vendors that include security questionnaires and compliance reviews. Yet the same organisation will add a third-party JavaScript tag — which has deeper access to user data than most SaaS integrations — with no security review at all. Marketing teams add analytics tags, A/B testing scripts, and chat widgets without security team involvement.

Each script is an ongoing trust relationship. The vendor can change the script's behaviour at any time by updating the file on their servers. A vendor that was trustworthy when the script was added might be acquired, compromised, or decide to monetise user data. Without SRI, you won't know when the script changes. Without CSP, you can't limit what it does.

Reducing Third-Party Exposure

The most effective control is reducing the number of third-party scripts. Every vendor removed is one fewer trust relationship to manage. For remaining vendors: self-host critical scripts to control updates, implement SRI for CDN-loaded resources, deploy CSP to limit capabilities, and regularly audit what scripts are actually loaded on your pages versus what you authorised.

ShieldReport analyses your domain's third-party script landscape, identifies scripts loaded without Subresource Integrity, evaluates your Content Security Policy's effectiveness, and flags the external dependencies that expand your attack surface — helping you manage the trust relationships your site depends on.