Subresource Integrity (SRI) lets a browser verify that a remotely hosted script or stylesheet contains exactly the bytes an author approved. The browser hashes the downloaded response and compares that digest with the page's integrity attribute. If the values differ, the resource is rejected instead of executed or applied.
What SRI Protects
A third-party CDN can be compromised, a file can be replaced accidentally, or an unversioned URL can begin serving a newer build. SRI turns the expected resource body into an explicit part of the page's security policy. It does not prove who wrote the file, but it prevents a different byte sequence from silently taking its place.
The check is exact. Changing a comment, line ending, minifier version, or even one whitespace byte creates a different digest. A legitimate resource update therefore requires a new integrity value.
Choosing the Input
The URL mode fetches the response in the browser and hashes the bytes it receives. This is the most direct workflow, but the resource server must allow the cross-origin request. If it does not, downloading the deployed file and using the local-file mode produces the same result without uploading that file anywhere. Pasted text is useful for content generated during a build, provided its UTF-8 encoding, whitespace, and line endings match the deployed resource exactly.
Some services vary responses by browser, compression negotiation, query parameter, or geography. SRI is appropriate only when a URL resolves to stable content. Versioned and immutable CDN URLs are much safer targets than aliases such as latest.
Hash Algorithms and Multiple Digests
SRI supports SHA-256, SHA-384, and SHA-512. All three are valid for SRI; SHA-384 is a common default that provides ample security margin without making the attribute unnecessarily long. Selecting several algorithms writes space-separated metadata expressions into one integrity attribute:
integrity="sha384-BASE64_DIGEST sha512-BASE64_DIGEST" When several recognized algorithms are present, browsers use the strongest supported algorithm represented in the set. Multiple digests are also useful during a controlled transition between policies, but they do not allow several different file versions under one URL. For that use case, immutable versioned URLs remain the reliable design.
Using the Generated Tag
A script resource needs the digest, its source URL, and usually anonymous cross-origin mode:
<script src="https://cdn.example.com/app.js"
integrity="sha384-BASE64_DIGEST"
crossorigin="anonymous"></script> A stylesheet uses the same metadata on its link element:
<link rel="stylesheet"
href="https://cdn.example.com/app.css"
integrity="sha384-BASE64_DIGEST"
crossorigin="anonymous"> For a cross-origin resource, the response also needs an appropriate Access-Control-Allow-Origin header. The crossorigin="anonymous" mode omits cookies and HTTP authentication credentials while enabling the CORS response check required for cross-origin SRI. A missing or unsuitable CORS response causes the resource load to fail; the browser does not silently ignore a valid integrity policy.
Generating the Same Value on the Command Line
OpenSSL can produce the digest from the exact deployed file. Prefix its Base64 output with the selected algorithm name:
printf 'sha384-'
openssl dgst -sha384 -binary app.js | openssl base64 -A
printf '\n' The browser tool and OpenSSL should return the same value when they receive identical bytes. A mismatch is useful evidence that the URL response differs from the local file, often because of an intermediary transformation, a stale cache, or browser-specific content negotiation.
Deployment Checklist
- Pin a versioned, immutable resource URL rather than an automatically updated alias.
- Generate the digest from the exact bytes served in production.
- Add
crossorigin="anonymous"and configure a compatible CORS response for cross-origin files. - Regenerate the integrity value whenever the resource changes.
- Test both successful loading and deliberate failure with a modified hash before deployment.