Cybersecurity glossary
What is Subresource Integrity (SRI)?
Learn what Subresource Integrity (SRI) is, how integrity hashes protect CDN scripts and stylesheets, how to generate SRI hashes, and limitations of SRI for web security.
Definition
Subresource Integrity (SRI) is a browser security feature that lets pages specify cryptographic hashes for external scripts and stylesheets so the browser loads them only if the fetched content matches the expected integrity value.
Why SRI exists
Modern sites pull JavaScript and CSS from CDNs. If that third-party file is replaced—by compromise, cache poisoning, or a bad publish—every site using it can execute attacker code.
Subresource Integrity (SRI) lets you pin the expected file contents with a hash the browser enforces.
How SRI works
Compute a hash of the file
Generate sha384 (or sha256/sha512) of the exact script or stylesheet bytes.
Add an integrity attribute
Place the hash on the script or link tag that loads the resource.
Browser fetches the resource
For cross-origin loads, CORS/`crossorigin` must allow integrity checking.
Compare and enforce
If hashes match, the resource runs; if not, the browser blocks it.
Example pattern (conceptual)
| Attribute | Purpose |
|---|---|
| integrity | Lists one or more base64 digests (sha384-...) |
| crossorigin | Enables CORS mode needed for cross-origin integrity checks |
| src / href | URL of the third-party or CDN asset |
When SRI helps most
CDN libraries
jQuery, analytics stubs, UI kits loaded from public CDNs.
Static vendor files
Version-pinned assets that rarely change.
Mirror risk reduction
Detects unexpected byte changes even if TLS looks fine.
Defense in depth
Pairs with CSP to shrink third-party script risk.
- Add SRI hashes for all critical third-party scripts and stylesheets.
- Include crossorigin when loading cross-origin resources with integrity.
- Automate hash generation in CI when vendor versions change.
- Prefer self-hosting critical libraries when operationally feasible.
- Combine SRI with a strict Content Security Policy.
- Monitor browser console reports for integrity failures in production.
- Do not expect SRI to sanitize malicious first-party code.
- Document ownership of each third-party dependency and update path.
The practical takeaway
Subresource Integrity pins the expected bytes of external scripts and styles so browsers reject unexpected changes. It is a strong control for CDN risk—not a complete script security program.
Hash what you load from others, update hashes when you intentionally upgrade, and keep CSP in place for everything else.
Related security terms
Content Security Policy (CSP)
Complements SRI by restricting which scripts may run.
Cross-Origin Resource Sharing (CORS)
Cross-origin SRI often requires proper CORS headers (crossorigin attribute).
HTTPS
SRI verifies content; HTTPS authenticates the transport to the CDN.
Man-in-the-Middle (MITM)
SRI helps detect compromised CDN responses even over HTTPS edges.
Frequently asked questions
What is SRI in simple terms?
You publish a hash of a JavaScript or CSS file. The browser downloads it and refuses to use it if the bytes do not match that hash.
What attacks does SRI stop?
It detects unexpected changes to third-party files—compromised CDNs, tampered mirrors, or accidental wrong versions.
Does SRI replace CSP?
No. CSP controls what may load and execute; SRI verifies the bytes of specific resources. Use both.
Why is the crossorigin attribute needed?
For cross-origin resources, browsers need CORS access to read the response for integrity checking. Use crossorigin appropriately.
What hash algorithms are used?
Browsers support sha256, sha384, and sha512 in the integrity attribute (often multiple hashes listed).
What are SRI’s limits?
It does not fix malicious-but-expected code, first-party XSS, or dynamically changing bundles without hash updates.
References
Explore authoritative guidance and frameworks related to subresource integrity (sri).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.