Skip to content
AdminKit

Subresource Integrity (SRI)

Subresource Integrity (SRI) lets a web page specify a cryptographic hash a fetched script or stylesheet must match before the browser executes it, blocking a tampered file from a CDN or third-party host. AdminKit's guide to judging header strength covers the related script-trust problem Content-Security-Policy addresses from the response side.

By AdminKit team, Netbase JSC · Updated

Read alongside AdminKit's guide to judging CSP strength -- SRI covers the same script-trust problem from the page's markup instead of a header

Subresource Integrity, a W3C specification, lets a page add an integrity attribute — a base64-encoded cryptographic hash — to a script or link tag loading a file from a CDN or other third-party host. Before executing the fetched file, the browser hashes it and refuses to run it if the result doesn’t match, which stops a compromised or tampered third-party host from silently serving different code than the page expects. OWASP’s Third-Party JavaScript Management Cheat Sheet lists SRI as one of the most effective controls available for this risk, alongside requiring CORS on the third-party host, which SRI needs to function at all. SRI protects against a tampered file from a source a page has chosen to trust; it does nothing to stop a page from loading a genuinely malicious script in the first place, which is the separate problem a strict Content-Security-Policy’s script-src directive addresses instead.