SRI

Subresource Integrity (SRI) is a browser security feature that verifies externally hosted resources (scripts, stylesheets) have not been tampered with by comparing their cryptographic hash against a known value.

Category: Security (also: Web Development)

Author: Atomic Glue Security Team

## Definition

SRI allows browsers to verify that files fetched from CDNs or other external origins match their expected content. When you load a script from a CDN, you add an integrity attribute containing a base64-encoded cryptographic hash (sha256, sha384, or sha512). The browser downloads the file, computes its hash, and compares it to the integrity attribute. If the hashes match, the resource is executed. If they do not match (indicating the file was modified, either maliciously or accidentally), the browser refuses to load the resource and reports a network error. SRI is critical for protecting supply chain integrity when using third-party-hosted assets.

## How SRI Works

The developer specifies the expected hash of a resource in the `integrity` attribute of a script or link element. Example: `<script src="https://cdn.example.com/library.js" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxC4kC8iVCx7YqS0vFJv7gH1q5" crossorigin="anonymous"></script>`. The browser downloads the resource, computes the hash using the specified algorithm, and compares it. A match means the resource is authentic. A mismatch means it has been altered, and the resource is blocked. The `crossorigin="anonymous"` attribute is required for CORS-enabled resources to expose the response body for integrity checking.

## Use Cases

**CDN-hosted libraries**: Verify that jQuery, Bootstrap, or other popular libraries served from CDNs have not been compromised. **Self-hosted assets**: Verify that your own static assets have not been modified between build and deployment. **Module federation / micro-frontends**: Verify the integrity of remotely loaded application modules.

## Limitations

SRI hashes must be regenerated every time the resource changes. This adds maintenance overhead for frequently updated CDN resources. Not all browsers support SRI (all modern browsers do, but older browsers ignore the attribute, so SRI is defense-in-depth, not a guaranteed block). Resources loaded via import() or dynamic script creation may not support SRI depending on how they are loaded.

## Note

Always include crossorigin="anonymous" for third-party CORS-enabled scripts. Without it, the browser cannot execute the integrity check and will silently skip verification.

## Common questions

Q: Can SRI prevent supply chain attacks?

A: Yes. If a CDN serving a JavaScript library is compromised and the library code is modified, SRI catches the modification because the hash will not match. This prevents the modified code from executing.

Q: How do I generate SRI hashes?

A: Online tools like srihash.org or the openssl command: cat library.js | openssl dgst -sha384 -binary | openssl base64 -A. Build tools like webpack and Vite can generate SRI hashes automatically.

Q: Does SRI work for dynamically loaded resources?

A: Yes, if you set the integrity attribute before appending the script element to the DOM. However, ES module dynamic imports do not support SRI natively.

## Key takeaways

• SRI verifies external resources haven't been tampered with via cryptographic hashes.
• Use the integrity attribute on script and link elements.
• Always set crossorigin="anonymous" for CORS-enabled SRI.
• SRI is defense-in-depth: not all browsers enforce it, but modern browsers do.

## Related entries

• [CSP](atomicglue.co/glossary/csp-backend)
• [Security Headers](atomicglue.co/glossary/security-headers)
• [XSS](atomicglue.co/glossary/xss)

Last updated December 2024. Permalink: atomicglue.co/glossary/sri