Subresource Integrity

Why It Matters

A page that pulls React or Tailwind from a public CDN is running code from a machine nobody on your team controls. If that CDN is compromised, or a maintainer publishes a bad version under an existing URL, every page pointing at it runs the new code the next time someone visits — silently, with full access to the page. That is the supply-chain risk SRI closes. The cost is rigidity: pin a hash and the file must never change, so a URL that tracks a moving version, such as one ending in 'latest', will break the first time it updates. Pinning therefore goes hand in hand with pinning the version number in the URL.

How It Works

The browser downloads the subresource, computes the digest of the received bytes with the algorithm named in the attribute, and compares it to the value given. On a match it executes the file; on a mismatch it discards it entirely and reports an integrity error in the console, as if the file had never loaded. Because the comparison is over the exact response body, any transformation on the way — a proxy that reformats, a CDN that injects a comment — causes a failure. Hashes are generated once at authoring time, either from the CDN's own copy-and-paste snippet or locally with openssl dgst using sha384 and base64 output. This is the same idea as a checksum on a downloaded file, enforced by the browser instead of by you.

Real-World Example

Common Mistakes

• ✕Pinning a hash against a URL that tracks the newest release — the next release changes the bytes and the page stops loading the file
• ✕Omitting crossorigin anonymous — without a CORS-clean response the browser cannot verify the hash and blocks the resource
• ✕Generating the hash from a local copy that differs from what the CDN serves, usually by a trailing newline, which fails every check
• ✕Expecting SRI to cover fonts, images or a script that another script injects at runtime — it only applies to script and link elements in the markup

Related Terms