Stylesheets via CDN without Subresource Integrity: How to Fix It

What this check flags

This check looks at every <link rel="stylesheet"> tag that points to a host you do not control, usually a public CDN, a font provider, or a third-party widget. When such a tag has no integrity attribute, we flag it. The browser has no way to verify the CSS it downloaded is the file you intended to ship; it simply trusts the response. If the CDN account is compromised, an edge node is poisoned, or a man-in-the-middle swaps the file, your visitors get whatever the attacker wrote, and you never find out.

Why SRI matters on stylesheets, not just scripts

People assume CSS is harmless because it cannot run code. That assumption is wrong. A hijacked stylesheet can hide your real content and reveal an injected overlay, push a fake login form into view, or rewrite what a page says. It can also exfiltrate data: attribute selectors combined with background-image requests can leak form field values, CSRF tokens, or anything in the DOM, one character at a time, back to an attacker's server. None of that requires a line of JavaScript. A poisoned CDN stylesheet is a quiet, capable attack surface, and exactly the weakness Subresource Integrity was built to close.

How integrity and crossorigin work together on link tags

SRI works by pinning a cryptographic hash of the file you trust. The browser downloads the stylesheet, hashes the bytes it received, and compares that to the hash in your integrity attribute. Match, and the CSS applies. No match, the browser blocks it. The hash format is sha256-, sha384-, or sha512- followed by the base64-encoded digest. SHA-384 is the common choice.

For any cross-origin resource you also need crossorigin="anonymous". SRI verification on a cross-origin file requires the request to go through CORS, and the CDN must return an Access-Control-Allow-Origin header that permits your site. Without the crossorigin attribute the browser can fall back to "fail-open" and skip the check entirely. Major CDNs already send the right CORS headers, so this is a one-line addition on your side.

<!-- Bad: no integrity, browser trusts whatever the CDN returns -->
<link rel="stylesheet" href="https://cdn.example.com/framework.css">

<!-- Good: hash pinned, CORS enabled -->
<link rel="stylesheet"
      href="https://cdn.example.com/framework.css"
      integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
      crossorigin="anonymous">

Generating the hash

Generate the hash from the exact file you intend to load. The simplest path on Mac or Linux is OpenSSL. Point it at the CSS file and it returns the base64 digest you paste after sha384-.

openssl dgst -sha384 -binary framework.css | openssl base64 -A

# Or pull straight from the CDN and hash what you actually receive:
curl -s https://cdn.example.com/framework.css | openssl dgst -sha384 -binary | openssl base64 -A

If you would rather not touch the command line, the SRI Hash Generator at srihash.org takes a URL and returns the complete <link> tag with the hash and crossorigin filled in. Either way, verify you hashed the real production file and not a redirect or error page.

The caveat: hashes break when files change

An SRI hash is tied to one exact version of a file. If the CDN ships a new build, even a single whitespace change, the hash stops matching and the browser blocks the stylesheet. That protects you from silent swaps, but it means you must point SRI-protected links at versioned, immutable URLs rather than a "latest" alias the provider rewrites underneath you. When you deliberately upgrade a library, regenerate the hash and update the tag in the same change. Treat the hash as part of the dependency.

How to fix it

Work through it in order. List every external stylesheet on the page. Confirm each loads from a versioned, immutable URL; if it points at a moving "latest" path, pin it to a specific version. Generate the SHA-384 hash for each file. Add integrity and crossorigin="anonymous" to each <link> tag. Then load the page and confirm the styles still render with no SRI errors in the console.

On WordPress, most stylesheets are queued through wp_enqueue_style, so you cannot just edit raw HTML. Use the style_loader_tag filter to inject integrity and crossorigin onto the CDN handles. Whatever system you run, the goal is the same: every cross-origin stylesheet ships with a pinned hash.

How to diagnose it

Open DevTools, go to the Network tab, and filter to CSS. Any stylesheet whose request domain is not your own is a candidate. View source and search for rel="stylesheet": every external one should carry both integrity and crossorigin. If you deliberately break a hash by changing one character, the Console prints a clear SRI mismatch message and blocks the file, which confirms the protection is active rather than failing open.

Common mistakes

Adding integrity but forgetting crossorigin="anonymous" on a cross-origin file is the most frequent error; the check can silently fail open. Hashing a local source file that differs from the minified version the CDN serves gives a hash that never matches. Pointing SRI at an unversioned URL guarantees the link breaks the next time the provider updates. And labeling a SHA-256 digest as sha384- blocks the file outright.

FAQ