How do I fix a missing subresource integrity attribute?

A missing subresource integrity attribute means the browser runs a third-party script without verifying that the bytes it downloaded match the bytes you approved. Subresource Integrity, defined by the W3C SRI specification, lets a page pin the cryptographic digest of an external resource so the user agent refuses to execute it if the contents change. MDN documents the integrity attribute on script and link elements as the way to attach that digest, which turns a missing subresource integrity attribute into a straightforward, additive fix.

Why this matters

When you load script from a content delivery network, that CDN, or anyone able to modify its response, can change the code that runs in your users' pages. With no integrity attribute the browser has no way to detect the swap, so a single compromised vendor response becomes script execution in your origin. SRI closes that gap by comparing the fetched resource against a hash you control, and the check happens before the resource is applied. The W3C specification defines digest options of SHA-256, SHA-384, and SHA-512; SHA-384 is the commonly recommended strength. A stronger hash costs nothing meaningful in page speed, because the browser computes it over bytes it has already downloaded. Integrity is not a substitute for trusting your vendor; it is a tripwire that turns a silent swap into a visible, blocked request, which is far easier to alert on. When a vendor serves only a rolling URL, mirror the file on your own origin and pin that copy instead.

How to fix it

An SRI-enabled script element carries three attributes: src, integrity, and crossorigin. The integrity attribute holds the algorithm name, a hyphen, and the base64 digest of the file. The crossorigin attribute set to the value anonymous is required, because the integrity check depends on a CORS-enabled fetch; without it the browser treats the resource as opaque and cannot validate it. Generate the digest with the same OpenSSL command you would use for a CSP hash, and regenerate it every time you bump the pinned library version.

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

# Compute the digest with OpenSSL
cat library.js | openssl dgst -sha384 -binary | openssl base64 -A

How to verify the fix

Open the document's network panel, inspect the script response, and confirm the browser did not block it for an integrity mismatch. If a legitimate script fails after you add SRI, one of three things is wrong: the digest does not match the served file, the file changed without a hash update, or crossorigin is missing. When you pin a version on a CDN, use the immutable versioned URL rather than a rolling one, so the digest keeps matching.

Related issues