Subresource Integrity is the simplest meaningful defense you can deploy against compromised third-party scripts, and it takes about ten minutes to add to most pages. Yet the majority of production sites still load external JavaScript with no integrity attribute at all. This post explains what SRI does, what it does not do, how to actually add it, and how to avoid the two failure modes that make developers give up on it.

What SRI actually does

When you load an external script with a plain src attribute, the browser fetches whatever is at that URL and runs it. No verification. If the CDN gets compromised, if the vendor ships a malicious update, if an attacker takes over the domain, your browser runs the new code.

Adding an integrity attribute tells the browser "this script should have exactly this SHA hash — anything else, refuse to execute." The browser downloads the script, computes the hash, compares against your declared value, and only runs the code if they match. If the served file changes in any way, the browser blocks execution and logs a console error.

It is a strict allowlist mechanism: either the code matches what you pinned, or it does not run at all. That is exactly the behavior you want for scripts you do not control but have to include.

Adding SRI to a script tag in five lines

A normal script tag looks like this:

With SRI, you add an integrity attribute with the hash, and crossorigin="anonymous" so the browser allows hash verification on cross-origin responses:

To compute the hash, you can use the openssl command line:

The output is your integrity value. Prepend "sha384-" and drop it in the attribute. Many CDNs also provide the SRI hash in their copy-paste embed snippet — if you use cdnjs, jsdelivr, or unpkg, you can grab the snippet with the hash already filled in.

The two failure modes that make people quit

First: vendor ships an update, your SRI hash does not match, the script silently fails, and a user-facing feature breaks. This is the primary operational cost of SRI and it is real. The mitigation is to only pin hashes on scripts that are actually versioned — cdn.example.com/v2.4.1/lib.js rather than cdn.example.com/latest/lib.js. If the URL itself is versioned, the hash only changes when the URL does, and you update both together.

Second: the vendor does not set CORS headers correctly, and the browser refuses to verify the hash, and you give up. The crossorigin="anonymous" attribute is mandatory for cross-origin SRI, and the server at the other end must respond with Access-Control-Allow-Origin headers. Most reputable CDNs do this already; some legacy internal services do not. If you control the other end, set the CORS header. If you do not, flag the script as a gap in your inventory and consider whether the vendor relationship is worth the risk.

What SRI does not cover

SRI pins a specific file. It does not pin what that file does after loading. A script that is identical to what you pinned but contains logic to dynamically fetch additional code from another domain will still execute that dynamic fetch — the SRI check only applies to the original file hash, not to anything it loads at runtime. The Polyfill.io attack in 2024 used exactly this pattern. SRI on the entry-point script did not protect against the payload loaded from a separate domain.

This is where Content Security Policy and runtime monitoring complement SRI. SRI stops the file from being swapped; CSP restricts which additional sources scripts can fetch from; monitoring catches anything that slips past both.

The ten-minute deployment plan

Pick your five highest-risk external scripts (payment, checkout, authentication, analytics, session handling). For each, find the CDN's recommended versioned URL and the SRI snippet. Replace your current script tags with the versioned URL plus integrity attribute plus crossorigin="anonymous". Deploy to staging, verify the scripts load, deploy to production. Schedule a reminder to update each pin when the vendor announces a new version. That is the whole lifecycle.

For the remaining scripts, add them to your inventory and decide whether the risk profile justifies the ongoing maintenance. Not every script deserves SRI — marketing pixels, analytics that your business depends on but whose integrity is not security-critical, etc. Use SRI where compromise would hurt; use CSP and inventory everywhere.