Subresource Integrity for Third-Party Scripts

Subresource Integrity, or SRI, lets a browser check that a downloaded script or stylesheet matches an expected digest. It is useful when you intentionally depend on a fixed external asset. The important operational question is how to keep that expectation synchronized with your deployment without accepting an unexpected change automatically.

SRI doesn't review the code for safety. It checks bytes against a value you chose. If you approve malicious code and compute its digest, the integrity check will faithfully accept that code. Use it as one part of dependency review rather than as a replacement for review.

Decide which assets can be pinned

A versioned library file with stable contents is a good candidate. A URL that changes its response continuously is harder to protect with a fixed digest. If a provider rewrites the asset behind a stable URL, your page can break when the bytes change.

Inventory external scripts and stylesheets. Record the purpose, owner, versioned URL and whether the dependency is essential. Remove unused assets before adding a new management process. Fewer third-party execution paths mean fewer updates to evaluate.

The browser SRI documentation describes the integrity attribute and supported SHA-based digest formats. Cross-origin use also depends on appropriate CORS behavior from the asset server.

Understand the digest representation

An SRI value combines an algorithm name with a Base64 representation of the binary digest. It is not simply the hexadecimal text returned by many checksum commands.

For example, an illustrative tag has this shape:

<script src="https://cdn.example/library-1.2.3.js"
        integrity="sha384-BASE64_DIGEST_OF_REVIEWED_BYTES"
        crossorigin="anonymous"></script>

The placeholder above is deliberately not a usable digest. Generate the real value from the reviewed file and verify it in a browser before deployment. Don't copy a digest from a different version or from a minified file when you load the unminified version.

Generate from the exact reviewed file

Download the versioned asset through the expected source, review its provenance and retain the exact bytes in your build process. A common command shape is:

openssl dgst -sha384 -binary library-1.2.3.js | openssl base64 -A

Prefix the resulting value with sha384- in the HTML attribute. Confirm the command's input path carefully. Hashing a saved error page or a local file that was reformatted produces a digest for the wrong bytes.

The SHA-256 Generator is useful for comparing controlled text samples during investigation. It isn't a substitute for hashing an arbitrary downloaded binary file exactly. Likewise, Base64-encoding a hexadecimal digest string does not produce the required SRI value.

Deploy the URL and digest together

Treat the asset URL and its digest as one reviewed change. Keep them in the same manifest or template so a partial deployment cannot mix a new file with an old expectation.

For a small site, a review record can include the old version, new version, source location, digest and affected pages. Compare that record in JSON Diff. Make the change easy to reverse if the new library causes application problems.

Avoid an automated process that fetches whatever a mutable URL currently serves and blindly approves a new digest. That would remove the protection against unexpected upstream changes. Automation should assist the review, not redefine approved bytes without a decision.

Test failure deliberately in staging

Confirm that the correct asset loads and the application works. Then use a controlled wrong digest in staging and confirm that the browser blocks the resource. Inspect the developer console and network panel to understand the resulting error.

Test a fresh session as well as a warmed cache. Verify every page template that includes the asset. A homepage may use the corrected tag while an old admin layout still references a different digest.

Decide how the product behaves when a dependency is blocked. An optional enhancement can fail gracefully. A checkout or authentication dependency needs an obvious error path and operational visibility. Don't remove integrity merely to hide a broken dependency.

Diagnose a mismatch methodically

Compare the actual fetched file with the file used during digest generation. Check the version, URL, redirects and whether the response is the expected JavaScript or CSS. Review CORS response behavior for cross-origin requests.

Use the HTTP Header Checker for public response-header inspection, but use your browser to test the actual script load. The checker doesn't execute JavaScript or prove the SRI check succeeded.

If an asset unexpectedly changed, pause its rollout and investigate. A legitimate vendor update and a compromised delivery path can both produce different bytes. The mismatch tells you to inspect the change; it doesn't explain the cause.

Combine with a reviewed loading policy

SRI applies to specific fetched assets. It doesn't automatically cover every script that a loaded dependency later adds. Inspect dynamic loaders and clarify which parts of the dependency tree remain outside the pinned boundary.

Keep your Content Security Policy and dependency inventory aligned with the intended loading paths. Avoid adding broad exceptions during troubleshooting. Preserve a small test page that reproduces the exact tag and origin behavior.

Conclusion

Use SRI for reviewed, stable assets and manage the URL and digest as one change. Generate the correct digest representation, test both success and intentional failure, and investigate mismatches before approving new bytes. Integrity is valuable when your update process preserves the meaning of approved code.