What Is Subresource Integrity (SRI)?

Subresource Integrity (SRI) is a browser security feature that lets a page specify a cryptographic hash of a script or stylesheet it expects to load, so that if a CDN or third-party host ever serves something different — through a breach, a misconfiguration, or a supply-chain attack — the browser refuses to execute it instead of silently running whatever arrived.

The problem it solves

Loading a library from a third-party CDN instead of your own server is common: it’s convenient, and popular libraries served from a shared CDN may already be cached in a visitor’s browser from another site. But it also means trusting that CDN’s infrastructure completely — anyone who compromises the CDN, intercepts the connection, or gains write access to that hosted file can inject arbitrary JavaScript into every site pulling from it. Given that a <script> tag runs with full access to the page’s DOM, cookies, and any data on screen, that’s a direct path to a cross-site scripting style compromise that has nothing to do with a vulnerability in your own code.

How it works

You add an integrity attribute containing a base64-encoded cryptographic hash of the expected file content, plus a crossorigin attribute (required for the browser to read cross-origin response data for verification):

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

Before executing the fetched file, the browser hashes the bytes it actually received and compares that hash against the integrity value. If they match, the script or stylesheet loads normally. If they don’t — because the file changed, whether through tampering or just an unannounced update — the browser blocks it entirely and the resource fails to load, the same way it would if the network request itself had failed.

Generating the hash

The hash is computed with SHA-256, SHA-384, or SHA-512 over the exact bytes of the file, then base64-encoded and prefixed with the algorithm name. Most CDNs that specifically advertise SRI support publish the correct integrity value alongside the script tag to copy, since the hash has to be generated from the exact file being served — it isn’t something you can compute in advance from a version number.

Multiple hashes and algorithm choice

The integrity attribute can list more than one hash, space-separated, each potentially using a different algorithm:

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

When multiple hashes are present, the browser only needs one of them to match — this is meant for a migration period between algorithms, not for listing multiple acceptable versions of a file. It doesn’t let a script pass integrity checks against several different legitimate file contents; it lets verification succeed as long as the file matches at least one of the hashes you’ve explicitly vouched for, computed from the one file you expect. SHA-384 is the most common choice in the wild — a reasonable balance between collision resistance and the length of the resulting attribute — though SHA-256 and SHA-512 are both valid and supported.

What SRI does and doesn’t cover

SRI verifies integrity, not identity or freshness. A few things worth being explicit about:

• It protects against tampering, not availability. If the file changes at all — even a legitimate update — the hash stops matching and the resource fails to load. That’s the intended behavior, but it means you must update the integrity attribute in lockstep with every version bump of the resource you’re loading, or your site breaks the next time the CDN pushes an update.
• It only applies to elements that support it — primarily <script> and <link rel="stylesheet">. It doesn’t cover images, fonts, or other resource types.
• It’s a complement to, not a substitute for, a Content Security Policy. A CSP restricts which origins a page is allowed to load resources from in the first place; SRI verifies that what actually arrives from an allowed origin is exactly what was expected. Using both together is a stronger posture than either alone: CSP narrows where scripts can come from, SRI checks that what comes from there hasn’t been altered.
• It requires CORS-friendly hosting. Because SRI verification needs to read the raw response bytes across origins, the resource must be served with permissive-enough CORS headers, or the browser can’t complete the comparison.

Generating an integrity hash yourself

If a third-party host doesn’t publish an integrity value for you to copy, you can compute one from the file directly: fetch the exact file you intend to load, run it through the chosen hash algorithm (commonly SHA-384), base64-encode the digest, and prefix it with the algorithm name — sha384- followed by the encoded hash. Most command-line hashing utilities and package-manager tooling can produce this in a single step. The important discipline is generating the hash from the exact bytes the browser will actually fetch at runtime, including whatever minification or bundling step produced the final file — hashing a pre-minified source file and then serving a minified version will simply fail every integrity check, since the two byte sequences are different files as far as the hash is concerned.

The takeaway

Subresource Integrity closes a gap that third-party script loading otherwise leaves open: it doesn’t stop a CDN from being compromised, but it stops a compromised or altered file from silently executing on your page. Add an integrity hash to any script or stylesheet loaded from a host you don’t fully control, keep it in sync whenever the resource updates, and pair it with a Content Security Policy for defense that covers both where scripts can load from and whether what loads matches what you expected.