2026-04-12·6 min read

Subresource Integrity (SRI) — Protect Your Site from Compromised CDNs

What is Subresource Integrity?

Subresource Integrity (SRI) is a browser security feature that lets you verify that scripts and stylesheets loaded from third-party CDNs have not been tampered with. When you add an `integrity` attribute to a `<script>` or `<link>` tag, the browser computes a cryptographic hash of the fetched file and compares it to the hash you specified. If they do not match, the browser refuses to execute the resource.

SRI is defined in a W3C specification and is supported by all major browsers — Chrome, Firefox, Safari, and Edge.

Why SRI matters

Modern websites rely heavily on third-party CDNs for JavaScript libraries like jQuery, Bootstrap, React, and analytics scripts. If an attacker compromises the CDN — or performs a man-in-the-middle attack — they can inject malicious code into every website that loads from that CDN.

This is not theoretical. In 2018, the event-stream npm package was compromised to steal cryptocurrency. In 2019, a Magecart attack injected card-skimming code via a third-party script on British Airways' website, affecting 380,000 transactions.

SRI stops these attacks at the browser level. Even if the CDN serves a tampered file, the browser will block it.

How SRI works

Step 1: Generate a hash

Use OpenSSL or the SRI Hash Generator to create a SHA-384 hash of your resource:

openssl dgst -sha384 -binary jquery-3.7.1.min.js | openssl base64 -A

Step 2: Add the integrity attribute

integrity="sha384-abc123..."

crossorigin="anonymous"></script>

The `crossorigin="anonymous"` attribute is required for SRI to work with cross-origin resources. Without it, the browser cannot access the response body to compute the hash.

Step 3: Add a fallback (optional)

If the integrity check fails, the resource will not load. For critical scripts, add a local fallback:

integrity="sha384-abc123..."

crossorigin="anonymous"></script>

Which resources support SRI?

**`<script>` tags** — fully supported

**`<link rel="stylesheet">` tags** — fully supported

**Dynamically loaded scripts** — supported if you set the integrity property before appending to the DOM

**Images, fonts, iframes** — not supported (SRI only covers scripts and stylesheets)

Common mistakes

Forgetting the `crossorigin` attribute — SRI silently fails without it on cross-origin resources

Using SHA-256 alone — SHA-384 is the recommended minimum; SHA-512 is even stronger

Not updating hashes after library upgrades — the integrity check will fail and block the resource

Applying SRI to resources that change frequently (analytics snippets, A/B testing scripts) — these will break every time the vendor updates the file

SRI and Content-Security-Policy

SRI works even better when combined with CSP. You can add the `require-sri-for` directive to your Content-Security-Policy header to enforce SRI on all scripts and styles:

Content-Security-Policy: require-sri-for script style

This ensures that any script or stylesheet without an integrity attribute is blocked — catching resources you may have missed.

How to audit your site

1. Use [CQwerty Shield's headers checker](/tools/headers-checker) to verify your CSP and security headers

2. View source on your pages and check every external `<script>` and `<link>` tag

3. Add integrity hashes to all third-party resources

4. Test thoroughly — a single wrong hash will break that resource

Key takeaways

SRI prevents tampered third-party scripts from executing in your users' browsers

Always use SHA-384 or SHA-512 hashes

Always include the `crossorigin="anonymous"` attribute

Combine SRI with Content-Security-Policy for defense in depth

Update hashes whenever you upgrade a library version

[Check your security headers now](/tools/headers-checker)

Ready to check your domain?

Run all 18 security checks in 2 minutes. Free, no signup required.

Check your headers →