Supply chain attacks on websites work by compromising a trusted third-party script or service, then using that access to attack every site that loads it. When attackers compromised the Polyfill.io CDN in 2024, over 100,000 websites instantly became vectors for malicious code — through a resource they had trusted and not changed. Every external script your site loads is a dependency you implicitly trust and do not directly control.

How Web Supply Chain Attacks Work

The mechanics are straightforward: your site loads a script from an external source. If an attacker gains control of that source — by compromising the CDN provider, acquiring the domain, taking over the package author's account, or exploiting a misconfigured CDN cache — every site loading that script immediately executes the attacker's code in the full context of your page.

That injected code runs with complete access to the page's DOM, all form inputs including payment card fields and passwords, cookies not protected by the HttpOnly flag, and the ability to make arbitrary network requests to any destination. This is the Magecart attack model: card skimmer scripts injected into checkout pages via compromised third-party dependencies, transmitting card numbers to attacker servers in real time as users type.

The Scale of the Exposure

The average production website loads resources from 8–12 distinct third-party domains. Each one is a potential supply chain vector that, if compromised, gives an attacker full script execution on your pages:

Each provider's security posture is effectively part of your site's security posture. A compromise at any provider immediately affects your users — without any code change on your end, without any deployment, and without any action your monitoring might detect.

Notable Real-World Attacks

Magecart (2016–present): A collective of threat actor groups that injects payment card skimmers into e-commerce sites by compromising third-party analytics and support scripts. Ticketmaster, British Airways, Newegg, and thousands of smaller retailers were affected. Stolen card data is transmitted to attacker-controlled domains in real time as customers complete purchases.

Polyfill.io (2024): A CDN providing widely used JavaScript polyfills was acquired by a company that began serving malicious code to mobile users from specific geographies. Over 100,000 websites were loading the script at the time of compromise. The attack redirected users to malicious sites and could not be detected by examining the sites themselves — only by analyzing the CDN's output.

ua-parser-js (2021): A popular npm package with 8 million weekly downloads was briefly taken over and updated to include a cryptocurrency miner and credential stealer. The malicious version spread automatically to any project that ran npm update during the window the compromised version was published.

Subresource Integrity (SRI)

SRI is a browser security feature that lets you specify a cryptographic hash of an external resource's content. The browser downloads the resource, computes the hash, compares it to your specified value, and only executes or applies it if they match. If the CDN serves modified content — whether maliciously injected or accidentally corrupted — the hash will not match and the browser will refuse to load the resource.

Implementation: add an integrity attribute containing a base64-encoded SHA-384 hash and a crossorigin="anonymous" attribute to the tag:

<script
  src="https://cdn.example.com/library.min.js"
  integrity="sha384-abc123XYZ..."
  crossorigin="anonymous"></script>

Generate SRI hashes via the command line: curl -s https://cdn.example.com/library.min.js | openssl dgst -sha384 -binary | openssl base64 -A, then prefix the result with sha384-. Or use the online SRI Hash Generator at srihash.org.

Key limitation: SRI only works for static, pinned resources. Scripts intentionally versioned and auto-updated by the provider (like analytics libraries that push updates automatically) cannot use SRI without manual hash updates after each provider change. For dynamic scripts, Content Security Policy is the complementary control.

Content Security Policy for Script Control

Content Security Policy (CSP) is a response header that explicitly declares which origins are allowed to load scripts, styles, fonts, and other resources on your page. A strict script-src directive blocks any script from an unauthorized origin — including injected scripts and compromised CDN content from domains not on your allowlist.

A practical example:

Content-Security-Policy:
  script-src 'self'
    https://www.googletagmanager.com
    https://js.stripe.com;
  object-src 'none';
  base-uri 'self';

This allows scripts only from your own origin, Google Tag Manager, and Stripe. Any script from any other domain — including a compromised CDN URL you are not explicitly using — is blocked. object-src 'none' blocks Flash and other plugins. base-uri 'self' prevents base tag injection attacks that redirect relative URLs.

Start with Content-Security-Policy-Report-Only mode to collect violation reports without blocking anything, review legitimate violations, then tighten and enforce. An overly broad CSP (containing 'unsafe-inline' or wildcard sources) provides little actual protection.

Practical Script Auditing

How Shieldome Checks This

Shieldome checks for Subresource Integrity as part of its OWASP A08 (Software and Data Integrity Failures) scan. When you run a Shieldome scan, it:

The finding output lists every external resource lacking SRI, grouped by domain, so you can see at a glance how many third-party dependencies your site has and identify which specific tags need integrity attributes added.

Frequently Asked Questions

Does SRI protect against all supply chain attacks?

SRI protects against attacks where the content of a pinned resource is modified — the most common Magecart-style injection through a compromised CDN. It does not protect against: new scripts added to your page by a compromised CMS or Tag Manager account (no SRI was defined for those tags), scripts you load without an integrity attribute (coverage gaps), or attacks that compromise your own origin server directly. SRI must be combined with CSP and access controls on your own systems.

Will adding SRI break my site if the CDN updates the script?

Yes, intentionally. If the CDN pushes an update and the content no longer matches your hash, the browser refuses to load the resource. This surfaces CDN updates as an explicit action you must review and approve — you generate a new hash for the updated content and deploy it. For resources that update frequently, self-hosting a pinned version or loading from a versioned URL eliminates this friction while keeping the security benefit.

What is Magecart and is my checkout page at risk?

Magecart is an umbrella term for threat actor groups that inject payment card skimmers into e-commerce checkout pages via compromised third-party scripts. Any site with a checkout page that loads external JavaScript is theoretically at risk. Sites that handle card entry directly in their own DOM (rather than using a hosted payment page from Stripe, PayPal, or a similar provider) are at higher risk because injected scripts can read card numbers as users type them. Using a hosted payment page — where card entry happens in an iframe on the payment provider's domain — eliminates most Magecart risk for that attack surface.

What is the difference between CSP and SRI?

SRI verifies that a specific resource has not been tampered with — it pins content by cryptographic hash. CSP controls which origins are allowed to load resources at all — it pins by source domain. They are complementary: CSP blocks scripts from unauthorized domains from loading in the first place; SRI blocks authorized domains from serving modified content. Full protection uses both: CSP to define the allowlist of permitted script sources, and SRI to verify the integrity of each resource on that list.

How do I generate an SRI hash?

Via command line: curl -s https://cdn.example.com/library.js | openssl dgst -sha384 -binary | openssl base64 -A, then prefix the result with sha384-. Or use the srihash.org web tool — paste the resource URL and it returns the complete integrity attribute value. Always verify the hash by running it against a locally downloaded copy of the file to confirm consistency before deploying.

Should I use SHA-256, SHA-384, or SHA-512 for SRI?

SHA-384 is the recommended default. SHA-256 provides 128 bits of collision resistance (sufficient), but SHA-384 provides 192 bits and is specified as the preferred option in many current security standards. SHA-512 is also supported by all major browsers but produces longer hashes without a meaningful practical security advantage over SHA-384 for this use case. Use SHA-384 as your standard.

Do I need SRI for first-party scripts hosted on my own domain?

No. SRI protects against a third party serving modified content — if you control the server serving the script, you control the content, and SRI provides no additional protection. SRI is specifically for external resources loaded from CDNs, analytics providers, and other third-party domains where you do not control the origin server.

Every external script your site loads is a trust relationship with a third party. Run a free Shieldome scan to see exactly which resources your site loads without SRI protection and get a specific list of integrity attributes to add.