What Is a Website Supply Chain Attack?

The Third-Party Script Problem

Modern websites rarely run only their own code. A typical ecommerce or marketing site loads scripts from analytics providers, advertising platforms, customer chat tools, payment processors, A/B testing tools, and tag management systems. Each of these scripts executes in the visitor's browser with the same permissions as the site's own code — including the ability to read everything the user types.

A supply chain attack exploits this trust relationship. Rather than attacking the target website directly — which may have reasonable security controls — the attacker compromises a third-party service that the website trusts and loads automatically. When the third-party service is compromised, every website that loads its script becomes a delivery mechanism for malicious code.

How Magecart Attacks Work

Magecart is the name given to a category of supply chain attacks that inject payment card skimming code into ecommerce checkout pages. The attack has operated since at least 2015 and has affected thousands of websites including British Airways (2018, 500,000 cards compromised) and Ticketmaster (2018).

The mechanism: the attacker compromises a third-party JavaScript library used by the target website — often a chat widget, a customer analytics tool, or an A/B testing library. They inject a small piece of additional JavaScript that, when the page contains a payment form, listens for form field input events and exfiltrates card numbers, CVV codes, expiry dates, and cardholder names to an attacker-controlled server. The exfiltration happens in the background; the payment completes normally from the customer's perspective.

The injected code is often highly obfuscated and designed to mimic legitimate analytics traffic to avoid detection. It may include logic to only activate on checkout pages, to detect security researcher environments and remain dormant, or to activate only during specific time windows.

What makes this attack particularly effective is that the website operator's own code is clean. Security scans of the website source find nothing suspicious. The malicious code lives in the third-party script, which is loaded at runtime and may change without the website operator's knowledge.

npm and CDN Compromise

Two other supply chain vectors are worth understanding:

**npm package compromise** — The JavaScript ecosystem depends on a vast number of open-source packages. When a widely-used package is compromised (either through account takeover of the maintainer, or by a malicious actor publishing a typosquatted package name), every site that installs or depends on that package potentially executes malicious code at build time or runtime. The `event-stream` compromise (2018), the `ua-parser-js` hijack (2021), and the `node-ipc` incident (2022) are documented examples.

**CDN-hosted library compromise** — Websites that load libraries directly from a CDN (`<script src="https://cdn.example.com/jquery.min.js">`) without integrity verification trust that the CDN will always serve the same file. If the CDN is compromised, or if the URL is updated to point to a new version, the website automatically runs the new code. This is also exploited through expired CDN domains — if a CDN used by many sites lets a domain lapse, an attacker who registers that domain can serve malicious scripts to every site still referencing it.

Subresource Integrity (SRI)

Subresource Integrity is a browser security feature that allows websites to verify that externally loaded scripts and stylesheets have not been tampered with. An SRI hash is a cryptographic hash of the expected file content, embedded in the script tag:

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

If the browser fetches the script and its hash does not match the value in the `integrity` attribute, the script is blocked and not executed. This prevents a compromised CDN from serving modified code — but only if the SRI hash in your HTML is correct and up to date.

SRI has a limitation: it only works for scripts with a fixed version hash. Scripts served from URLs that always return the latest version cannot use SRI, because the hash would be outdated immediately after a legitimate update.

Content Security Policy for Script Control

A Content Security Policy (CSP) can restrict which domains are allowed to load scripts on your pages. A strict `script-src` directive that whitelists only known-good domains prevents the browser from executing scripts loaded from unexpected sources, including newly injected third-party references.

``` Content-Security-Policy: script-src 'self' https://analytics.example.com https://cdn.trusted.com; ```

CSP does not prevent attacks through already-whitelisted domains (if `cdn.trusted.com` itself is compromised, a permissive CSP offers no protection), but it significantly reduces the attack surface by preventing the attacker from loading external resources from domains not in the allowlist.

For a detailed guide on implementing CSP, [what is Content Security Policy](/blog/what-is-content-security-policy) covers the directives and tradeoffs.

Practical Controls

Maintain an inventory of every third-party script loaded on your website. For each one, understand what data it has access to and what happens if it is compromised. Apply SRI hashes to any scripts loaded from fixed versions. Implement a CSP that restricts script sources. Monitor for unexpected new scripts appearing on your pages — automated tools can alert you when a new external domain loads on your site.

For checkout pages specifically, consider a stricter CSP that blocks all third-party scripts, loading only your payment provider's script and your own. The attack surface on a page that handles payment card input deserves more scrutiny than a marketing page.

Yrzo AI's automated security assessment checks for CSP headers, SRI hash implementation, and third-party script exposure across your site. From yrzoai.dev.