Subresource Integrity (SRI): Protect Your Site from CDN Compromises

The CDN Trust Problem

When you load a JavaScript library from a CDN — jQuery, Bootstrap, React — you trust that the file hasn't been tampered with. But CDNs can be compromised. If an attacker modifies a library on a CDN, every site using that library becomes a victim.

This isn't theoretical. In 2018, the event-stream npm package was compromised to steal cryptocurrency. In 2019, a Magecart attack through a third-party script affected thousands of e-commerce sites. Supply chain attacks on CDN-hosted scripts are a real and growing threat.

How SRI Works

Subresource Integrity lets you include a cryptographic hash of the expected file. The browser downloads the resource, computes its hash, and compares it to the expected value. If they don't match, the browser refuses to execute the script or apply the stylesheet.

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

The integrity attribute contains the hash algorithm and the base64-encoded hash value. The crossorigin="anonymous" attribute is required for SRI to work on cross-origin resources.

Generating SRI Hashes

Using openssl

cat library.js | openssl dgst -sha384 -binary | openssl base64 -A

Using the SRI Hash Generator

For remote files, you can use the command-line:

curl -s https://cdn.example.com/library.js | openssl dgst -sha384 -binary | openssl base64 -A

Supported Hash Algorithms

• sha256 — Minimum recommended
• sha384 — Most commonly used (good balance of security and length)
• sha512 — Maximum security

You can include multiple hashes for fallback. This is useful when transitioning between file versions:

integrity="sha384-abc123... sha384-def456..."

When to Use SRI

SRI should be used on:

• Third-party scripts loaded from CDNs (jQuery, analytics libraries, UI frameworks)
• Third-party stylesheets from CDNs (Bootstrap CSS, Font Awesome)
• Any external resource where you need content integrity guarantees

SRI is not needed for:

• First-party assets served from your own domain (you control them)
• Dynamically generated content (hash would change every time)
• Resources loaded from trusted, version-pinned endpoints you control

SRI with CDN-hosted Frameworks

Major CDNs provide SRI hashes on their sites. For example, Bootstrap's documentation includes the integrity hash in every installation snippet:

<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css"
      rel="stylesheet"
      integrity="sha384-9ndCyUa..."
      crossorigin="anonymous">

Limitations and Gotchas

• Breaks with dynamic resources: If the CDN serves different versions based on user agent or other headers, SRI will fail unpredictably. Only use SRI with files that have a single, stable hash.
• Version pinning required: Always pin to a specific version (e.g., bootstrap@5.3.0), not a "latest" tag. If the file changes, the hash won't match.
• CORS required: SRI only works on cross-origin resources if the server sends proper CORS headers. The crossorigin="anonymous" attribute triggers a CORS request.
• No support for CSS @import: SRI only works on <script> and <link rel="stylesheet"> tags, not on resources loaded via CSS @import rules.

Require SRI via CSP

You can enforce SRI for all scripts and styles using Content Security Policy:

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

This tells the browser to refuse loading any script or stylesheet that doesn't have a valid integrity attribute. Note: this CSP directive has limited browser support — check compatibility before relying on it.

Check Your SRI Coverage

Scan your website with WebSentry to see which external scripts and stylesheets are missing SRI hashes. The audit flags every third-party resource loaded without integrity verification.