Subresource Integrity (SRI) is a browser feature that lets you attach a cryptographic hash to a script or stylesheet you load from a third party, so the browser refuses to execute the file unless its contents hash to exactly the value you specified. It exists to solve one specific and dangerous problem: when you load code from a CDN, you are trusting that CDN to serve the same file forever. If the CDN is compromised, its domain is hijacked, or an insider swaps the file, every site embedding that script executes the attacker's code. SRI turns that silent substitution into a hard failure, because a modified file no longer matches the hash.
The June 2024 polyfill.io incident is the canonical illustration. After the cdn.polyfill.io domain changed hands, it began serving malicious JavaScript to an estimated 100,000-plus websites that embedded its script directly, redirecting mobile users to scam sites. Sites that had pinned a known-good version with SRI were protected, because the tampered file failed its integrity check. The short answer for 2026: put an integrity hash on every static third-party script and style you can, pin those resources to immutable versioned URLs, and understand that SRI cannot protect content that is designed to change.
How SRI works
You add two attributes to the tag: integrity, holding a base64-encoded hash prefixed with the algorithm, and crossorigin, which is required so the browser performs a CORS-enabled fetch and can read the response to verify it.
<script
src="https://cdn.example.com/lib@3.2.1/lib.min.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>
When the browser downloads the file, it computes the SHA-384 digest of the bytes it received and compares it to the integrity value. On a match, the script runs. On a mismatch, the browser blocks the resource entirely and reports an error. You can list multiple hashes separated by spaces to allow more than one acceptable version during a rollout.
Generating the hash is a one-line operation you can run in a build step:
# Produce the sha384 integrity value for a file
cat lib.min.js | openssl dgst -sha384 -binary | openssl base64 -A
Prefer SHA-384 or SHA-512 over SHA-256; all three are valid, but the longer digests give more margin and are the common recommendation.
Where SRI stops
SRI is powerful precisely because it is strict, and that strictness is also its limit. It protects static, immutable resources. It cannot protect a resource that legitimately changes on every request, which is exactly why polyfill.io was hard to pin in the first place: it served browser-specific bundles that differed per user agent, so there was no single stable hash to lock to. The real lesson of that incident is not only "use SRI" but "do not depend on a third-party endpoint that ships mutating, unversioned code into your page."
SRI also does nothing for resources loaded outside its scope: it applies to script and link (stylesheet) elements and, in modern browsers, module scripts and import maps via an integrity field, but not to images, fonts, or content injected by an already-running third-party script. And a hash proves a file is unchanged, not that it was safe to begin with; if you pin a malicious version, SRI faithfully guarantees you keep running the malicious version.
SRI adoption checklist
- Add
integrityandcrossorigin="anonymous"to every static third-partyscriptandlink. - Pin to immutable, versioned URLs, never a "latest" or unversioned path.
- Use SHA-384 or SHA-512 digests, generated automatically in your build.
- Self-host critical dependencies where feasible instead of trusting a shared CDN.
- Avoid third-party endpoints that serve dynamic, unversioned code into your pages.
- Monitor for integrity failures so a blocked resource surfaces as an alert, not a broken page.
- Remember SRI verifies sameness, not safety; you still need to vet what you pin.
How Safeguard helps
SRI is one layer of front-end supply chain defense, and it works best alongside knowing exactly what third-party code your application pulls in. Safeguard's software composition analysis inventories your dependencies, including the front-end libraries you might otherwise load from a CDN, and flags known-vulnerable versions so you do not pin a bad one. Dynamic application security testing observes what your live pages actually load and can surface risky third-party scripts and missing integrity protections, while Griffin AI explains the exposure and the fix. Developers enforce these checks in CI with the Safeguard CLI, and teams comparing platforms can review the pricing.
Know and control every script your users run: get started free or read the documentation.
Frequently Asked Questions
What problem does Subresource Integrity solve?
It stops a compromised or hijacked CDN from silently swapping the code your site loads. By pinning a cryptographic hash to a third-party script or stylesheet, the browser refuses to execute the file if its contents change, which is what protected SRI-using sites during the 2024 polyfill.io supply chain attack.
Why do I need the crossorigin attribute with SRI?
The browser must be able to read the fetched response to compute and compare its hash, and that requires a CORS-enabled request. Without crossorigin="anonymous" (and appropriate CORS headers from the CDN), the integrity check cannot run and the resource is blocked.
Can SRI protect resources that change over time?
No. SRI verifies that a file matches a fixed hash, so it only works for static, immutable resources pinned to versioned URLs. Endpoints that serve dynamic or per-browser bundles, like polyfill.io did, cannot be pinned, which is a signal to self-host or drop that dependency rather than trust it.
Does SRI guarantee a script is safe?
No. It guarantees the script is unchanged from the version you pinned, not that the version was safe. If you pin a malicious or vulnerable file, SRI faithfully keeps serving it. Combine SRI with dependency scanning so the version you lock to is one you have actually vetted.