Subresource Integrity and Third-Party Script Security Explained

Analytics, chat widgets, payment SDKs, font loaders, A/B testing tools - the average site loads a surprising number of scripts it didn't write, from origins it doesn't control. Each one is a standing grant of full code execution on your page.

What You're Actually Trusting

A <script src="https://cdn.vendor.com/widget.js">tag doesn't just load a file once - it runs whatever that URL serves, every single time a browser requests the page, with the same access to the DOM, cookies, and user input as your own first-party code. If that vendor's CDN is compromised, or a build pipeline pushes a bad update to a shared path, every site referencing it is affected the moment a browser next loads the page - no action required on your part at all.

This isn't a hypothetical - supply-chain compromises of widely-used JavaScript libraries and analytics snippets have happened, at scale, more than once. The attack doesn't target your site specifically; it targets the shared dependency every site referencing it inherits automatically.

What Subresource Integrity Actually Verifies

SRI lets you tell the browser, in advance, exactly what file you expect at a given URL - as a cryptographic hash. If the file the browser actually downloads doesn't match that hash byte for byte, the browser refuses to execute it (or apply it, for a stylesheet) and logs a console error instead.

Applying it to a script

<script src="..." integrity="sha384-..." crossorigin="anonymous"></script>

The crossorigin attribute is required alongside integrity- without it, the browser can't read the response bytes to check the hash, and silently skips the verification entirely.

What SRI Doesn't Solve

• Availability. If the CDN is down or the URL 404s, your page still breaks whatever depended on that script - SRI only decides whether to run a file that did load, not whether one loads at all.
• A vendor shipping a legitimately updated (but unreviewed) file. If the vendor changes the file at the same URL for a real update, the hash mismatch just breaks your integration until you regenerate it - which is precisely the point, but it does mean you own re-verifying every update rather than trusting it blindly.
• A first-party script you host yourself.SRI exists for resources you load from an origin you don't control - your own hosted files don't need it, since a compromise there is a different problem entirely.

A Practical Adoption Path

• Prioritize scripts that run on every page and touch sensitive flows first - payment SDKs, auth widgets, anything with DOM-wide access.
• Pin to a specific, versioned CDN URL rather than a "latest" alias - most vendors publish per-version URLs specifically so SRI hashes stay stable.
• Most CDNs (cdnjs, jsDelivr) publish the correct SRI hash directly alongside their script tag - copy it from there rather than generating your own when available.
• Apply the same treatment to third-party stylesheets, not just scripts.