flashman
← All guides

Check a subresource integrity attribute

Check subresource integrity by using the strongest hash in the attribute, comparing it with the fetched bytes, and setting crossorigin for other origins.

2026-10-15 · 8 min read

  • sri
  • security
  • frontend

Subresource Integrity lets a page pin the bytes of a script or a stylesheet. The integrity attribute carries one or more tokens. Each token is an algorithm name, a hyphen, and the standard base64 of the raw digest. If the verification fails, the browser refuses to execute the script or apply the stylesheet.

The HTTP status can still be 200. Look at the console and at the response body before you change the server status or the cache headers.

Verify the strongest token only

sha256, sha384, and sha512 are the algorithm names browsers use for this attribute. If more than one token is present, the browser picks the strongest algorithm it supports and checks that digest. It does not fall back to a weaker token that would have matched.

A deploy that adds a new sha512 and leaves last release's sha256 will break as soon as the stronger hash is wrong. Recompute every token from the file you are about to serve, or publish only one algorithm and rotate it deliberately.

  • Use standard base64, including padding.
  • Do not paste a hex digest into the attribute.
  • Do not paste base64url, which uses minus and underscore.
  • Drop tokens you are not willing to recompute.

Hash the bytes the browser executes

The digest covers the response body after content-encoding is removed. Hashing the gzip member on disk produces a different value from hashing the script the browser runs. A trailing newline, a UTF-8 BOM, or a minifier pass does the same.

An HTML rewriter, a tag manager, or a service worker that inserts bytes after the hash was computed will fail a correct-looking attribute. Capture the response body from the browser and diff it with the file you hashed.

Send CORS for a cross-origin target

A cross-origin script or stylesheet with integrity is fetched with CORS. Set crossorigin to anonymous unless the resource needs cookies. The server has to answer with Access-Control-Allow-Origin that allows the page. A correct digest still fails when that header is missing.

Same-origin resources do not need the CORS header. If a CDN hostname and the page hostname differ, treat the resource as cross-origin even when you operate both names.

Use the hash tool on the text, not on the token

Flashman's hash tool turns the text you paste into SHA-256 or SHA-512 hex. Use it to prove that two copies of a script differ, including a copy that gained a newline in the textarea. It does not emit an integrity attribute, and it has no SHA-384 mode.

The Base64 tool encodes and decodes UTF-8 text. Encoding the hex digest as text does not produce the SRI token, because the token is the base64 of the raw digest bytes. Diff the two script bodies, then compute the token with a byte-oriented hash. Keep the attribute, the URL, and the file digest together in the deploy note.

Try these tools