SRI

SRI (Subresource Integrity) is an HTML5 feature that lets you pin the SHA-256/SHA-384/SHA-512 hash of an external resource. The browser computes the hash on download and refuses to execute the resource if the hashes don’t match.

Example: <script src="https://cdn.example/lib.js" integrity="sha384-AbC..." crossorigin="anonymous"></script>

What this protects against: a CDN compromise. If an attacker takes over the CDN and serves modified JavaScript, every site that includes the script via SRI refuses to run the modified version. Without SRI, every site silently gets the malicious payload.

The trade-off: pinning a hash means you can’t update the resource without updating every page that references it. For first-party assets you’re building anyway, SRI is a low-cost defence. For third-party CDN scripts (jQuery, analytics tags) it’s a meaningful security win at the cost of slower update propagation.

SRI requires crossorigin="anonymous" on the tag plus a CORS header on the CDN response — the browser needs to be able to read the response opaquely.

Real-world incidents SRI would have stopped: the Magecart family of card-skimming attacks repeatedly compromised third-party JavaScript hosted by trusted vendors (BrowserAloud, Inbenta, Picreel) and injected card-stealing code that loaded into thousands of e-commerce checkout pages. Ticketmaster’s 2018 breach and British Airways’ 2018 breach both involved attackers modifying scripts on hosts the affected sites included via <script src="…">. SRI is the specific mitigation: had those sites pinned the integrity hash of the script version they meant to load, the modified payload would have failed the check and the browser would have refused to execute it.

How to generate and rotate SRI hashes pragmatically: for files you own, the build pipeline should emit SRI hashes alongside the asset bundle and inline them into the HTML at template time (Next.js, Vite, and Webpack all support this with plugins). For third-party libraries, the recommended workflow is to lock to a specific version, copy the file to your own CDN, and SRI-pin that — relying on the upstream CDN to keep the same bytes available at the same URL is risky over months. The integrity attribute accepts multiple hashes separated by spaces, allowing for hash-algorithm transitions (ship SHA-384 and SHA-512 together; the browser picks whichever it supports). Related: CSP, SHA-256. Reference: W3C — Subresource Integrity.

Worked example

You want to include jQuery 3.7.1 from a CDN with SRI protection. Compute the SHA-384 hash of the file: openssl dgst -sha384 -binary jquery-3.7.1.min.js | openssl base64 -A outputs something like Bu3qSpvxnAdMaOTsigCcfqUyJYvP7AbsxRRpzqj7M1V2OuoP1bb98c8MQYIPHzxc. Embed it: <script src="https://code.jquery.com/jquery-3.7.1.min.js" integrity="sha384-Bu3qSpvxnAdMaOTsigCcfqUyJYvP7AbsxRRpzqj7M1V2OuoP1bb98c8MQYIPHzxc" crossorigin="anonymous"></script>. On page load, the browser fetches the file, computes its SHA-384, base64-encodes it, and compares to the integrity attribute. If the CDN serves a tampered file — even a single-byte change — the hashes diverge, the browser blocks execution, and a SecurityError appears in DevTools. The page still renders; only the failed-integrity script is suppressed.

When and why it matters

Any time your site loads JavaScript from a domain you don’t control, you are trusting that domain’s operators, their CDN provider, their DNS, and every step of TLS in between. That trust is empirically misplaced often enough to matter: supply-chain compromises affecting npm packages, jQuery plugins, GTM containers, and analytics scripts have hit major sites at a rate of several per year. SRI is the defence that doesn’t require trusting the third party. The pragmatic deployment strategy: SRI-pin third-party scripts you load by URL (CDN-hosted libraries, embedded widgets), but not scripts you bundle and ship from your own origin where you control the bytes. Combine with CSP require-sri-for script (proposed but not yet widely implemented) or script-src with explicit allowed hashes for defence in depth. Reference: MDN — Subresource Integrity.