Gera Tools

Subresource Integrity (SRI) Reference

SRI integrity attribute format with hash algorithm options and crossorigin notes.

Reference for the Subresource Integrity integrity attribute syntax, supported SHA-256/384/512 hash algorithms, the crossorigin CORS requirement and an integrity string parser. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What does the integrity attribute do?

It pins a cryptographic hash of the exact resource bytes the browser expects. After download the browser hashes the file and compares; if it does not match, the resource is blocked. This protects against a tampered or swapped CDN file.

Pinning third-party scripts and styles

Subresource Integrity (SRI) lets a page declare the cryptographic hash a <script> or <link rel="stylesheet"> resource must match. If a CDN is compromised or the file is altered in transit, the browser refuses to execute or apply it. This reference covers the integrity attribute syntax, the allowed hash algorithms and the crossorigin requirement, with a live parser.

How it works

An integrity value is one or more space-separated tokens. Each token is an algorithm prefix and a base64-encoded digest of the resource’s raw bytes:

<script
  src="https://cdn.example.com/lib.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>

The prefix is sha256-, sha384- or sha512-. The base64 payload decodes to a digest of 32, 48 or 64 bytes respectively, so the encoded string has a fixed length per algorithm (44, 64 and 88 base64 characters including = padding). On download the browser hashes the bytes with the named algorithm and compares to the pinned digest; a mismatch blocks the resource.

Why SRI matters for CDN-hosted scripts

A CDN delivering a JavaScript library is a supply-chain trust point. If the CDN’s storage is compromised — which has happened to several popular CDN hosts — the attacker can replace a library with a version that steals credentials or injects malware, and every site loading the file is immediately affected. SRI makes this attack class ineffective: even if the CDN delivers a modified file, your users’ browsers will refuse to execute it because the hash does not match the one you embedded at build time.

This is distinct from HTTPS, which only guarantees the file came from the CDN, not that the CDN itself was not compromised. SRI pins the exact bytes, so the security guarantee extends through the CDN to the original file.

Generating a hash on the command line

The openssl command produces a correct SRI hash directly:

openssl dgst -sha384 -binary lib.js | openssl base64 -A

Prepend sha384- to the output and you have the integrity token. For SHA-512 substitute sha512. Most CDN providers — jsDelivr, cdnjs, Bootstrap’s CDN — display pre-computed SRI hashes alongside their embed codes, so you rarely need to compute them manually.

Multiple hashes and algorithm migration

You can list hashes for more than one algorithm separated by spaces. The browser accepts the resource if any one hash matches and uses the strongest algorithm present when multiple match. This lets you ship sha256- sha384- together during an algorithm transition: old browsers that support only SHA-256 accept it, while modern browsers verify the stronger SHA-384.

Tips and notes

  • Generate a hash with openssl dgst -sha384 -binary file.js | openssl base64 -A.
  • Always pair cross-origin SRI with crossorigin="anonymous" or verification is skipped and the resource is blocked.
  • List several hashes (space-separated) to migrate algorithms without breaking older builds.
  • Recompute the hash on every file change — even a whitespace edit changes the digest.
  • SRI covers script and link; it does not protect images or other element types.
  • If the CDN uses cache-busting filenames (e.g., lib.v2.1.3.js), update the hash every time you update the version — the hash from the old file will not match.