Subresource Integrity (SRI) lets you add a cryptographic hash to a script or stylesheet tag. The browser downloads the file, hashes it, and refuses to run it if the hash does not match — protecting you if a CDN or third-party host is compromised.
When you load JavaScript or CSS from a third party, you trust that host completely. SRI removes that blind trust: the browser verifies the file matches an expected hash before executing it, defending against supply-chain attacks where a CDN file is swapped for a malicious one.
Check your website
See how your site handles subresource integrity: verifying third-party scripts — free, no account needed.
For business owners
Some of the most damaging breaches happen when a trusted third-party script is quietly modified to skim card details or credentials from thousands of sites at once. SRI is a simple, standards-based control that ensures the code running on your pages is exactly what you approved — protecting customers from attacks you would otherwise never see coming.
How it works (technical)
Add an integrity attribute containing a base64 hash prefixed with the algorithm, plus crossorigin="anonymous":
<script src="https://cdn.example.com/lib.js"\n integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"\n crossorigin="anonymous"></script>
If the fetched file's hash does not match, the browser blocks it. Use sha384 or sha512. SRI works best for versioned, immutable files; it is unsuitable for resources that change on every request (you would have to update the hash each time). Generate hashes at build time and update them when you deliberately upgrade a dependency.
Real-world example
A widely used analytics script hosted on a third-party CDN was compromised and briefly served malicious code. Sites that pinned the script with SRI were protected — their browsers detected the hash mismatch and refused to execute the tampered file, while sites without SRI ran the attacker's code.
Why it matters
SRI defends against third-party and CDN supply-chain compromise. Scanners note externally hosted scripts loaded without an integrity attribute as a hardening opportunity.
How to fix it
Identify third-party scripts and stylesheets loaded from external hosts.
Generate a
sha384orsha512hash for each versioned file.Add the
integrityattribute pluscrossorigin="anonymous"to the tag.Update the hash whenever you intentionally upgrade the dependency.
Prefer pinned, versioned URLs so the file (and its hash) is stable.
Best practices
Apply SRI to all third-party scripts and styles that support it.
Use immutable, versioned URLs so hashes remain valid.
Combine SRI with a Content Security Policy for defence in depth.
Common mistakes
Loading critical third-party scripts with no integrity check at all.
Applying SRI to files that change frequently, causing them to break.
Forgetting to update the hash after a deliberate library upgrade.
Frequently asked questions
Does SRI work for any file?
It works for scripts and stylesheets that are stable and versioned. It is not suitable for resources that change on every request, since the hash would no longer match.
Is SRI a replacement for CSP?
No — they complement each other. CSP controls which sources may load; SRI verifies the exact contents of a specific file. Use both for strong supply-chain protection.
Put this into practice
See how your site scores with Plexa Trust — start with a free scan, then unlock the complete audit on Pro.
Scan your website free