Subresource Integrity (SRI)
Subresource Integrity pins a cryptographic hash to a script or stylesheet so the browser refuses to execute content that does not match the expected digest.
Definition
Subresource Integrity is a security feature in which a link or script element carries a base64 hash of the expected resource, and the browser verifies the fetched bytes against it before use.
Context and scope
It protects pages that load code from a CDN or any third-party origin that could be compromised or silently altered.
Common misconceptions
- SRI protects the resource from modification in transit only
- integrity is checked again on every subsequent navigation
Anti-patterns
- pinning a hash without a build step that updates it on release
- using SRI on a URL that is rewritten or personalised
Related concepts
Related examples
Authoritative source
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
Definition
Subresource Integrity is a security feature in which a link or script element carries a base64 hash of the expected resource, and the browser verifies the fetched bytes against it before use.
It protects pages that load code from a CDN or any third-party origin that could be compromised or silently altered. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.
When to use it
A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.
How it works
The integrity attribute holds one or more algorithm-prefixed digests, and the browser blocks the resource when none matches, failing closed rather than falling back to unverified code.
Because the hash must match byte for byte, any CDN transformation such as minification or an injected banner invalidates it, so integrity hashes belong to immutable, versioned URLs.
Trade-offs and alternatives
SRI does not cover the initial HTML document or resources loaded by scripts at runtime, so it complements rather than replaces a strong Content Security Policy. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.
Common misconceptions
A persistent misconception is that SRI protects the resource from modification in transit only. Another is that integrity is checked again on every subsequent navigation. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.
Anti-patterns to avoid
Two recurring anti-patterns are to pinning a hash without a build step that updates it on release and to using SRI on a URL that is rewritten or personalised. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Preconnect and DNS-Prefetch Hints, Fetch Priority Signals, Speculative Parsing and Preload Scanner.