integrity

Overview

Subresource Integrity (SRI) lets the browser verify that files fetched from CDNs or other third-party servers have not been tampered with. You provide a cryptographic hash of the expected file contents, and the browser checks the downloaded file against that hash before executing or applying it.

If a CDN is compromised and serves a modified file, the browser will refuse to use it rather than running potentially malicious code. SRI is a critical defense-in-depth measure for any site that loads resources from third-party origins.

How It Works

1. You generate a cryptographic hash of the resource file.
2. You add the hash to the integrity attribute, prefixed with the algorithm name.
3. You add crossorigin="anonymous" (required for cross-origin resources).
4. When the browser downloads the file, it computes the hash and compares it to your value.
5. If the hashes match, the resource loads normally. If they do not match, the browser refuses to execute or apply the resource and reports a network error.

Hash Format

The integrity value is an algorithm prefix followed by a base64-encoded hash, separated by a hyphen:

SHA-384 is the most common choice. It offers strong security with reasonable hash length.

Applies To

The integrity attribute is supported on two elements:

• <script> — verify JavaScript files
• <link rel="stylesheet"> — verify CSS files

Examples

Script with SRI

Stylesheet with SRI

Multiple Hashes

You can provide multiple hashes separated by spaces. The browser will accept the resource if any of the hashes match. This is useful when migrating between hash algorithms or when a resource may be served in different valid forms.

When multiple hashes with different algorithms are provided, the browser uses the strongest algorithm it supports for verification.

The crossorigin Attribute

For cross-origin resources, integrity must be paired with the crossorigin attribute. Without it, the browser cannot read the response to verify the hash (due to CORS restrictions) and will skip the integrity check.

Same-Origin Resources

For resources served from the same origin, crossorigin is not required. SRI still works, but since you control both the page and the resource, it is less commonly needed.

Generating Integrity Hashes

You can generate hashes from the command line or use the online tool at srihash.org.

Workflow Tips

• Pin to exact versions: SRI hashes are tied to exact file contents. Always use versioned URLs (e.g. lib@3.2.1) rather than latest or unversioned paths.
• Regenerate on update: When you update a dependency version, regenerate the hash.
• Build tools: Bundlers like Webpack, Vite, and Parcel can generate integrity hashes automatically.

What Happens on Mismatch

When the downloaded file does not match the expected hash:

• The browser refuses to execute the script or refuses to apply the stylesheet.
• A network error is reported (visible in DevTools console).
• The element fires an error event, which you can handle to show a fallback or alert the user.
• No partial execution occurs — the resource is completely blocked.

This is intentional. A mismatched hash means the file has been modified, and it is safer to break functionality than to run potentially malicious code.

Common Mistakes

• Forgetting crossorigin on cross-origin resources. Without it, the integrity check is silently skipped.
• Using unversioned CDN URLs (e.g. lib/latest/lib.js). When the CDN updates the file, the hash breaks. Always pin to a specific version.
• Whitespace or encoding differences: The hash must match the exact bytes served. If a CDN minifies or re-encodes a file differently, the hash will fail.
• Copying hashes from untrusted sources: Generate hashes yourself from a known-good copy of the file, not from the same CDN you are verifying.