JavaScript via CDN without Subresource Integrity: How to Fix It

What this check flags

This audit item fires when a page pulls in JavaScript from an external host (a CDN, a third party widget, a font or charting library) using a script tag that has no integrity attribute. Your site is telling the browser to download and run code from a server you do not control, with no way to confirm the code it received is the code you expected. Every flagged tag is a spot where someone who can change that remote file can change what runs on your site.

What SRI is and why it matters

Subresource Integrity lets you pin a cryptographic hash to a remote file. You compute a hash of the exact file you trust, put it in the script tag, and the browser computes its own hash of whatever it actually downloaded. If the two match, the file runs. If they do not match, the browser discards the file and never executes it.

Here is the scenario it defends against. CDNs are shared infrastructure. If one is compromised, an account is hijacked, or a file is replaced in transit, the attacker can push a modified script to every site that loads it. That script runs with full access to your pages: it can skim form fields, inject ads, redirect checkout, or steal session data. Without SRI, visitors quietly run that hostile code. With SRI, the hash no longer matches, the browser blocks the file, and the attack fails on your site. It costs you a one time hash and protects against a whole class of supply chain attacks.

The integrity and crossorigin attributes

Two attributes do the work. The integrity attribute holds the algorithm and the hash, written as a prefix plus a base64 value, for example sha384 followed by a dash and the hash. SHA-384 is the common, recommended choice; SHA-256 and SHA-512 also work. The crossorigin attribute is not optional. Cross-origin files checked with SRI must be fetched using CORS, so set crossorigin="anonymous" to make the browser request the file without sending credentials. Leave crossorigin off and the browser cannot read the raw bytes it needs to verify the hash, so it "fails open" and loads the file as if no integrity check existed, quietly throwing away the protection.

<!-- BAD: no integrity, browser cannot verify the file -->
<script src="https://cdn.example.com/lib/widget.min.js"></script>

<!-- GOOD: pinned hash plus crossorigin so the check actually runs -->
<script src="https://cdn.example.com/lib/widget.min.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>

How to generate the hash

You can generate a hash from the command line, or use a generator like srihash.org which hands back the full tag. From a terminal, point OpenSSL at the exact file you intend to ship:

# Produce the full integrity value, prefix included
echo "sha384-$(openssl dgst -sha384 -binary widget.min.js | openssl base64 -A)"

# Output looks like:
# sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC

Hash the same versioned file the browser will fetch, then paste the result into the integrity attribute. Many CDNs and libraries already publish SRI hashes in their install snippets, so check the vendor's copy paste code before computing your own.

The caveat: files that change

SRI pins one exact set of bytes. The moment the remote file changes, the hash stops matching and the browser blocks it. That is exactly what you want for a versioned library at a stable URL, where the file never changes without a new URL. It is the wrong tool for a file that updates in place under the same URL, which is how some analytics and tag scripts work. Pin one of those and your tracking can break the next time the vendor pushes an update. Rule of thumb: use SRI for stable, versioned files, and for self updating third party scripts either pin a specific version that does not move or accept that SRI does not fit. If you must keep a self updating file, plan to refresh the hash whenever it changes, ideally automated in your build.

How to fix it

Work through the flagged tags one at a time. For each external script: confirm it loads from a stable, versioned URL; generate the SHA-384 hash of that file; add integrity with the hash and crossorigin="anonymous" to the tag; then reload the page and confirm the script still runs. On WordPress these tags usually come from a theme, a plugin, or a tag manager rather than raw HTML, so the fix may mean updating the plugin that injects the script or filtering the script output to append the attributes. Get the hash right for the exact version you serve, and re-check after any update that bumps the file.

How to diagnose

View source or open developer tools and look at every script tag with an src pointing to another domain. Any that lack integrity are your candidates. To confirm a hash works, load the page with developer tools open and watch the Console: a mismatch produces a clear integrity error and the blocked file shows as failed in the Network tab. If a script that should run is silently missing, a wrong or stale hash is the usual culprit.

Common mistakes

The frequent one is adding integrity but forgetting crossorigin="anonymous", which makes the browser fail open and verify nothing. Close behind is hashing the wrong file, often a different version or a non-minified copy, so the hash never matches. People also pin self updating analytics scripts and then wonder why tracking breaks. Match the hash to the exact file at the exact URL you ship.

FAQ