CSS No SRI

Element Code: SE-015

What Subresource Integrity is and what the flag means

Subresource Integrity, SRI, is a browser feature defined by the W3C. You put a cryptographic hash of the exact file you expect into the integrity attribute of a <script> or <link> tag. When the browser downloads the resource, it hashes what it received and compares. Match, it applies the file. Mismatch, it blocks the file entirely and logs a console error. Simple, and effective.

This check fires when a stylesheet is pulled from an external origin (a public CDN, a font or widget host, a third party design kit) using a bare <link rel="stylesheet" href="..."> with no integrity attribute. That means your page will trust and render whatever CSS that host serves at request time, with no verification that it is the file you intended.

Why unverified third party CSS is a real risk

People wave this away with "it is only CSS, what is the worst that happens." More than you would like. CSS is not passive decoration. It can:

• Exfiltrate data. CSS attribute selectors combined with background image requests can leak the contents of form fields and hidden tokens to an attacker controlled server. This is a documented class of attack, not theory.
• Deface and phish. Malicious CSS can hide the real UI, overlay a fake login prompt, reposition buttons over links, or swap your branding, all without touching a line of your HTML.
• Break the page. Even a botched or corrupted file from the CDN wrecks your layout for every visitor until someone notices.

The threat model that matters is supply chain: you do not control the CDN. If that host is compromised, its account is hijacked, or a rogue update ships, your visitors silently receive weaponized bytes served from your own page. This is exactly the pattern behind real world CDN and third party script incidents. SRI is the seatbelt. It does not stop the crash on the CDN, it stops the crash from reaching your users, because the hash will not match and the browser refuses the file.

How SRI verification flows

The fix, concretely

A protected stylesheet link looks like this. Two attributes get added: integrity with the algorithm prefixed base64 hash, and crossorigin="anonymous", which SRI requires for cross origin resources so the response is fetched in a way the browser can validate.

<link rel="stylesheet"
  href="https://cdn.example.com/lib/3.4.1/lib.min.css"
  integrity="sha384-9ndCyUa...base64hash...=="
  crossorigin="anonymous">

Step by step:

1. Pin a version. SRI only works against an immutable file. Reference a specific version URL, never a "latest" or floating path, because the hash of latest changes without warning and blocks your own site.
2. Generate the hash. Use the SRI Hash Generator at srihash.org, or on the command line: openssl dgst -sha384 -binary file.css | openssl base64 -A, then prefix with sha384-. Prefer sha384 or sha512 over sha256.
3. Add both attributes. Put the integrity and crossorigin="anonymous" attributes on the link tag.
4. Test in a browser. Load the page, open DevTools, and confirm the stylesheet applies and there is no integrity error in the console. Then flip one character of the hash and confirm the browser blocks it, so you know the guard is live.
5. Repeat for every external stylesheet the check flagged, and script it into your build so new dependencies get hashed automatically.

SRI at a glance

How to detect it

1. Screaming Frog: crawl and check the resource and security reports, or use custom extraction to flag external <link rel="stylesheet"> tags that lack an integrity attribute.
2. Browser DevTools: the Network tab shows every external CSS request and its origin, and the Security or Issues panel surfaces missing integrity warnings.
3. Security scanners: tools like Mozilla Observatory and various header and dependency scanners report missing SRI on subresources.
4. Manual source check: grep the rendered HTML for external stylesheet links and confirm each cross origin one carries integrity plus crossorigin.

Do this / skip that

What good looks like

Every stylesheet you pull from an origin you do not control carries a pinned version, an sha384 or sha512 integrity hash, and crossorigin="anonymous". Your build regenerates those hashes on every dependency bump so they never go stale. If a CDN ever serves altered CSS, your visitors get a blocked resource and a console error instead of a hijacked page. That is the trade you want: fail closed, not silently compromised.

FAQ