Subresource Integrity (SRI)

Subresource Integrity (SRI) lets a browser verify that a fetched external resource matches an expected cryptographic hash. It helps detect unexpected modification of resources such as scripts and stylesheets loaded from another origin.

SRI is specified by adding an `integrity` attribute to supported resource elements, commonly `<script>` and ``. The attribute contains one or more cryptographic digests, such as a SHA-384 hash, representing the exact bytes the browser is expected to receive.

When the browser fetches an SRI-protected resource, it computes the corresponding digest of the retrieved content and compares it with the declared digest. If the content does not match, the resource is blocked rather than executed or applied. This makes SRI useful when an application depends on resources delivered through a CDN or another external origin.

For cross-origin resources, SRI works together with CORS requirements. The resource must be fetched in a way that permits the browser to inspect its response for integrity verification; for typical cross-origin script usage, this means the server needs an appropriate CORS response. SRI does not itself establish that the external provider is trustworthy; it verifies that the bytes match the value specified by the page.

A hash must correspond exactly to the resource version being loaded. Updating a dependency changes its bytes and therefore normally requires updating the corresponding integrity value. Hashes should be generated from the actual resource contents rather than guessed or manually edited.

Key points

• `integrity` declares an expected cryptographic digest for a resource.
• The browser hashes the fetched bytes and compares the result with the declared digest.
• A digest mismatch causes the protected resource to be rejected.
• SRI is especially useful for third-party resources served through CDNs.
• Cross-origin SRI usage can require CORS-compatible resource delivery.

Interview questions

What problem does Subresource Integrity solve?

SRI lets a web page specify the expected cryptographic hash of an external resource. The browser calculates a digest for the fetched bytes and compares it with that expected value. If they differ, the browser rejects the protected resource. This helps detect unexpected changes to CDN-hosted or otherwise externally delivered assets.

How does SRI work for a cross-origin script?

The script includes an `integrity` attribute containing an accepted digest, often using SHA-384 or another supported hash algorithm. The browser fetches the script and verifies its bytes against that digest. For a cross-origin resource, the request and response also need to satisfy the applicable CORS requirements so the browser can perform the integrity check. A mismatch prevents the script from being used.

Why can't you keep the same SRI hash after upgrading a CDN dependency?

An SRI digest represents the exact bytes of the protected resource. Changing the dependency version normally changes those bytes, so the old digest no longer describes the new file. The integrity value must therefore be regenerated from the new resource contents. This is intentional because accepting the old hash would defeat the byte-level verification.

Does SRI make a CDN trustworthy?

No. SRI does not establish that the CDN, package author, or resource itself is trustworthy. It establishes that the bytes delivered to the browser match the digest chosen by the application. If an attacker or maintainer can change both the resource and the page's integrity value, SRI does not provide an independent trust anchor. SRI is therefore one layer in a broader web supply-chain security strategy.

What should you consider when choosing an SRI hash algorithm?

The algorithm needs to be one supported for SRI and strong enough for the security requirements of the application. SHA-384 is a common choice in practical examples, while stronger supported algorithms can also be used. The important operational requirement is that the digest be generated from the exact resource bytes and updated whenever those bytes legitimately change. Multiple integrity metadata values can also be supplied when supporting different acceptable representations.