Subresource Integrity Pins Browser Execution to Expected Bytes
A web page can fetch JavaScript and stylesheets from infrastructure outside the application’s deployment boundary. A CDN improves distribution, but the browser normally treats the response from the referenced URL as the resource the page requested. If that response changes unexpectedly, transport security alone does not tell the browser that the bytes differ from the version selected by the application operator.
Subresource Integrity (SRI) adds a content check to that load. The page carries cryptographic metadata for an expected representation. A supporting browser hashes the fetched resource and accepts it only when the result satisfies the declared integrity metadata.
The digest belongs to the selected artifact
A script element can carry an integrity attribute:
<script
src="https://cdn.example.com/app.min.js"
integrity="sha384-BASE64_DIGEST"
crossorigin="anonymous"></script>The value combines a hash algorithm identifier with a Base64-encoded digest. SRI supports integrity metadata using SHA-256, SHA-384, and SHA-512. The digest is calculated over the resource representation that the browser validates, so a byte change produces a different result except for the collision properties of the selected hash function.
This creates a useful separation between location and content. The src URL says where the browser should fetch the script. The integrity metadata states which content is acceptable at that location.
The digest must come from a trusted build or release path. Copying a digest from the same compromised delivery location as the resource defeats that separation: an attacker able to replace both the artifact and the metadata can make the pair consistent again.
A mismatch stops the resource load
For a resource carrying integrity metadata, the browser computes the relevant digest after fetching the response and compares it with the acceptable metadata. If no acceptable digest matches, the browser rejects the resource instead of executing the script or applying the stylesheet.
That failure mode matters for externally hosted JavaScript. Without SRI, control of the delivery endpoint can become control of code executed in the page’s origin context. With a correctly pinned digest, changing the hosted file without changing the page’s accepted metadata causes the load to fail.
SRI is therefore a fail-closed content check, not an availability mechanism. A modified CDN response can still break the page by causing the resource to be rejected. The control limits which bytes are accepted; it does not make the remote host reachable or guarantee that a dependency remains available.
Cross-origin integrity also depends on CORS
Integrity checks for cross-origin resources operate with CORS. A common external script declaration therefore includes:
<script
src="https://static.example.net/library.js"
integrity="sha384-BASE64_DIGEST"
crossorigin="anonymous"></script>The resource server must return an appropriate Access-Control-Allow-Origin response header for the request. The crossorigin="anonymous" setting places the element load in CORS mode without sending cross-origin credentials such as cookies or HTTP authentication credentials.
This requirement prevents integrity metadata from becoming a mechanism for probing opaque cross-origin responses through success and failure signals. A deployment that adds an integrity attribute but leaves the CDN without suitable CORS behavior can turn a previously successful load into a failure.
Multiple digests can support controlled transitions
The integrity attribute can contain multiple space-separated digest expressions. When metadata uses more than one supported algorithm, browser processing gives precedence to the strongest algorithm represented by valid metadata rather than treating weaker entries as independent fallbacks.
Multiple digests using the same selected algorithm can represent more than one acceptable resource body. This can support a controlled transition when a page must temporarily accept two known artifact versions.
That flexibility should be deliberate. Every accepted digest expands the set of content the browser may load. Old values should not remain indefinitely after a rollout completes, especially when the older artifact contains code that is no longer intended for use.
Version movement requires metadata movement
SRI deliberately conflicts with mutable asset URLs. If https://cdn.example.com/library.js changes from one release to another while the HTML keeps the old digest, the browser rejects the new bytes.
Immutable or versioned asset URLs fit the model better:
https://cdn.example.com/library/4.2.1/library.min.jsA release can then update the URL and digest together as one reviewed change. Build systems may generate integrity metadata automatically, but the generated value still needs to travel through a trusted publication path with the HTML that references it.
This also makes rollback behavior explicit. Restoring an earlier HTML document restores the digest and URL selected by that document, rather than silently accepting whatever a mutable endpoint currently serves.
SRI narrows one supply-chain boundary
SRI does not authenticate the publisher of a dependency and does not prove that the expected artifact is benign. If malicious code is already present when the digest is selected, the browser will faithfully accept that malicious code because it matches the declared value.
It also cannot protect a page when an attacker can modify the page itself. Control of the HTML allows replacement of the resource URL, the integrity metadata, or both. The trust anchor for SRI is therefore the document and the process that places expected digests into it.
SRI complements HTTPS rather than replacing it. TLS protects the connection and authenticates the HTTPS endpoint according to the browser’s certificate validation. SRI adds a separate constraint on the fetched representation. The two controls address different boundaries.
Content Security Policy can add another layer by constraining which script sources or execution patterns a document permits. SRI is narrower: for a resource that carries integrity metadata, it binds acceptance to expected bytes.
Operational checks belong in the release path
A practical deployment verifies the digest against the exact production artifact before publishing the referencing page. It also confirms CORS behavior for cross-origin resources and tests the failure path so a digest mismatch is visible in browser diagnostics and monitoring.
Dependency updates should change the artifact reference and integrity metadata together. Reviewers can then see that a content change has an accompanying digest change instead of receiving an unexplained production failure later.
The useful security property is precise. A browser presented with valid integrity metadata does not execute or apply a covered resource merely because it arrived from the configured URL. The fetched bytes must also match content that the page explicitly accepted.