Questions › Networking/Security

Subresource Integrity and third-party script risk

Supply-chain SecurityHardNetworking/Security

Your app loads a third-party script from a CDN. What's the supply-chain risk, how does Subresource Integrity help, and what are its limits?

What it tests

Awareness of third-party/supply-chain script risk and the specific role (and boundaries) of SRI.

Approach & answer

Every third-party script you load — an analytics snippet, a tag manager, a charting library from a CDN — runs with your ORIGIN'S FULL PRIVILEGES: it can read the DOM, cookies (non-HttpOnly), and localStorage, make authenticated requests as the user, and rewrite the page. So a third-party script is a trust decision equivalent to giving that vendor code-execution on your users. The supply-chain risk: you don't control that file. If the CDN is compromised, the vendor is breached, or an attacker hijacks the account/domain, the served script can be swapped for a malicious one and every visitor to your site is attacked (the Magecart card-skimming attacks worked exactly this way — poisoning a widely-included third-party script). SUBRESOURCE INTEGRITY (SRI) defends against the file being TAMPERED WITH: you add an integrity attribute containing the cryptographic hash of the exact file you vetted (integrity="sha384-...") plus crossorigin="anonymous". The browser fetches the resource, hashes it, and REFUSES TO EXECUTE it if the hash doesn't match — so a modified script simply won't run. This pins the content: you're no longer trusting 'whatever the CDN serves today', you're trusting 'the specific bytes I hashed'. SRI's LIMITS are important and often missed: (1) It only verifies the ONE file you pinned. If that script dynamically loads FURTHER scripts at runtime, those aren't covered — SRI doesn't transitively protect the dependency graph. (2) It protects against tampering, NOT against a malicious version being what you pinned in the first place, and it breaks 'auto-updating' scripts — many analytics/tag vendors ship a tiny loader that always pulls the latest code, which is fundamentally incompatible with a fixed hash (you'd have to re-hash on every vendor update). (3) It doesn't reduce the PRIVILEGE the script has once it does run legitimately. So SRI is necessary but not sufficient. The fuller defense-in-depth posture: pin versioned files with SRI where you can; minimize the number of third-party scripts and prefer self-hosting vetted copies; constrain them with a strict CSP (allowlist exact sources; 'strict-dynamic' + nonces so only trusted loaders run); ISOLATE risky third-party widgets in a sandboxed iframe so they don't share your origin's privileges; use Permissions-Policy to strip capabilities; and monitor with CSP violation reports. The mental model: SRI freezes the bytes, CSP limits the sources, iframes limit the privilege — you need all three because a third-party script is untrusted code running in your users' sessions.

Use this technique when

Adding a CDN/third-party script; explaining supply-chain risk; deciding SRI vs CSP vs sandboxing.

Code

<!-- Third-party script runs with YOUR origin's full privileges. -->
<!-- Risk: CDN/vendor compromise swaps the file -> every visitor attacked (Magecart). -->

<!-- Subresource Integrity pins the exact bytes you vetted: -->
<script src="https://cdn.example.com/lib@1.2.3/lib.min.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>
<!-- Browser hashes the fetched file; hash mismatch -> script is BLOCKED. -->

<!-- SRI limits:
     - covers only THIS file, not scripts it loads at runtime
     - breaks auto-updating loaders (hash must change per version)
     - doesn't reduce the privilege the script has once it runs -->

<!-- Defense in depth: SRI (freeze bytes) + strict CSP (limit sources)
     + sandboxed iframe for risky widgets (limit privilege) + Permissions-Policy. -->

References