Subresource Integrity Binds External Assets to Cryptographic Digests

A web page can load JavaScript and CSS from an origin outside its own deployment boundary. That arrangement is convenient for shared packages and content delivery networks, but it also delegates part of the page’s execution or presentation path to the server that returns those resources.

Subresource Integrity (SRI) adds a byte-level constraint to that dependency. The page supplies one or more cryptographic digests in an integrity attribute. A supporting browser fetches the resource, computes a digest with the declared algorithm, and accepts the response only when the bytes satisfy the integrity metadata.

<script
  src="https://cdn.example.net/app.min.js"
  integrity="sha384-BASE64_DIGEST"
  crossorigin="anonymous"></script>

The digest does not identify a publisher or prove that a file is benign. It states a narrower condition: the fetched representation must match bytes approved by the page author.

Integrity metadata is tied to exact content

An SRI token combines an algorithm name with a Base64-encoded digest. Common metadata uses SHA-256, SHA-384, or SHA-512.

sha384-BASE64_DIGEST

A one-byte change produces a different cryptographic digest with overwhelming probability for a secure hash function. That means minification changes, banner insertion, rebuilt source maps embedded in a file, or any other byte change requires new integrity metadata.

This property makes SRI deliberately strict. A URL may remain unchanged while its response changes, but an old digest does not silently authorize the new representation. The browser rejects a response that fails the integrity check instead of executing or applying it as the requested subresource.

That behavior also means mutable asset URLs require operational care. If a deployment replaces app.min.js in place, the HTML carrying its digest must be updated in coordination with the asset. Content-addressed or versioned asset names reduce that coordination problem because a new representation naturally receives a new reference.

The page remains the authority for the approved digest

SRI is useful when the HTML and the external asset do not share the same compromise boundary. An attacker who can alter only the external asset cannot make arbitrary replacement bytes satisfy a digest already fixed in uncompromised HTML.

The boundary changes if the attacker can modify both surfaces. If the same compromise permits replacement of the script and modification of the page’s integrity value, the attacker can publish a digest for the malicious replacement. SRI does not create independence between two artifacts that are controlled through the same compromised path.

This distinction matters in deployment design. The security value comes from anchoring the expected digest in a surface with an integrity boundary separate from the resource being constrained.

Cross-origin fetch rules still apply

SRI does not bypass the browser’s cross-origin model. For cross-origin subresources, integrity checking interacts with CORS processing, and the resource must be delivered in a way that permits the browser to use the response for the requested mode.

A common external script form therefore pairs integrity with crossorigin="anonymous":

<script
  src="https://static.example.net/vendor.js"
  integrity="sha384-BASE64_DIGEST"
  crossorigin="anonymous"></script>

The crossorigin attribute is not a second hash check. It controls the CORS settings used for the fetch. The integrity attribute supplies the expected digest metadata. Both participate in whether the external resource can be used, but they enforce different conditions.

Deployment testing should cover the actual response headers and browser request path. A correct digest alone cannot repair a CORS configuration that prevents the resource from being accepted.

Multiple digests support controlled transitions

The integrity attribute can contain multiple metadata tokens separated by whitespace. This permits a page to declare more than one acceptable digest where the processing rules allow it.

<script
  src="/bundle.js"
  integrity="sha384-DIGEST_A sha384-DIGEST_B"></script>

Multiple values should not be treated as a generic escape hatch for mutable content. Every accepted digest expands the set of representations that the page author has authorized. Old values should be removed when they are no longer required.

Algorithm selection also matters. Browsers evaluate integrity metadata according to the SRI processing model, including how supported algorithms and multiple options are handled. Applications should generate metadata with tooling that emits supported algorithms and should preserve the exact output rather than manually rewriting digest strings.

SRI constrains content, not delivery freshness

A matching digest says that the received bytes equal an approved representation. It does not state that the representation is the newest release.

A cache, intermediary, or origin can return an older asset that still matches a digest currently listed by the page. If rollback resistance or strict release freshness is required, version selection and deployment policy must enforce that property separately.

SRI also does not replace HTTPS. TLS protects the transport channel, server authentication, and response integrity in transit. SRI adds an application-declared expectation about the subresource bytes. The controls address different boundaries and are commonly used together.

Dynamic loading needs an integrity-aware design

Static HTML makes the digest visible beside the resource URL. Runtime loaders can complicate that relationship if code constructs script or stylesheet elements dynamically.

A loader that receives an arbitrary URL and inserts it without integrity metadata does not gain SRI protection merely because other resources on the page use SRI. The expected digest has to travel through the loading path and be attached to the resource request in the form required by the browser.

Build systems can make this manageable by producing an asset manifest that records versioned URLs and corresponding digests. The application can then render both values from one deployment artifact. The manifest itself becomes security-relevant because changing a URL-digest pair changes the set of accepted external bytes.

Failure must be treated as a dependency failure

When an integrity check fails, the protected resource is unavailable to the page. Applications should not respond by silently retrying the same dependency without integrity metadata, because that converts a verification failure into an unverified load.

The safer operational model treats the event like any other critical dependency failure. Monitoring can record failed asset loads, deployment health checks can verify published HTML against deployed assets, and release procedures can prevent a page from referencing a digest that does not match the resource at its target URL.

For scripts, failure may stop application startup. For stylesheets, presentation may degrade. Those availability costs are part of the contract: SRI chooses rejection over accepting bytes outside the page’s declared set.

The digest is a narrow, useful trust anchor

SRI does not certify source code, audit a package, or establish publisher identity. It also cannot protect a page whose own HTML can be rewritten by the same adversary that controls the external asset.

Its contribution is more precise. A page can bind a subresource reference to approved bytes, and the browser can enforce that binding before using the response. For external scripts and stylesheets whose hosting path sits outside the page’s primary deployment boundary, that check turns an implicit dependency on whatever a URL returns into an explicit dependency on a specific cryptographic representation.