Subresource Integrity Pins External Resources to Expected Bytes

Loading a script or stylesheet from another host creates a direct dependency on the bytes that host returns. TLS protects the connection in transit, but it does not state that the response is the exact object the page operator intended to execute or apply.

Subresource Integrity (SRI) adds that byte-level condition. An HTML element can carry integrity metadata containing one or more cryptographic digests. A supporting browser fetches the resource, computes the relevant digest, and uses the response only when the result satisfies the metadata.

This control is narrow by design. SRI does not authenticate a user, authorize a request, inspect JavaScript behavior, or make third-party code safe. It binds a resource reference to expected content.

Integrity metadata carries the expected digest

A script reference can include a digest alongside its URL:

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

A stylesheet can use the same mechanism:

<link
  rel="stylesheet"
  href="https://cdn.example.net/app.min.css"
  integrity="sha384-BASE64_DIGEST"
  crossorigin="anonymous">

The metadata token combines a hash algorithm name with a Base64-encoded digest. Common SRI metadata uses algorithms such as sha256, sha384, or sha512. The digest must be produced from the resource representation expected by the browser’s integrity algorithm; it is not a filename, version label, or certificate fingerprint.

A mismatch causes the protected resource to be rejected. For a script, that means the fetched response is not executed through that element. For a protected stylesheet, the mismatched response is not applied through that link.

The browser performs this decision at load time. Application code does not need to fetch the object first and compare a hash afterward.

A digest pins content, not a hostname

SRI changes the trust statement made by a resource reference. Without integrity metadata, a page effectively accepts whatever eligible response arrives from the referenced URL. With SRI, the URL and digest form a tighter condition: the resource must come from the requested location and match approved bytes.

That distinction matters when a CDN, package mirror, object store, or other delivery tier is outside the application’s direct deployment boundary. A valid HTTPS response from that infrastructure can still contain bytes different from the version selected by the page operator. SRI can prevent those changed bytes from being used by the protected element.

The protection also applies to accidental replacement. A deployment that overwrites a stable asset URL with a new build while HTML still carries the old digest produces a load failure instead of silently accepting the new object.

That behavior is both the security property and an operational constraint. Every intentional byte change requires matching integrity metadata in the referencing document.

Cross-origin loads also involve CORS

Integrity checking does not erase the browser’s cross-origin rules. For resources fetched from another origin, the response must also satisfy the conditions required for SRI and cross-origin fetching. A common pattern uses crossorigin="anonymous" on the element and configures the resource server with an appropriate CORS response.

The two controls serve different roles. CORS determines whether a cross-origin response is eligible to be shared in the relevant browser context. SRI checks whether eligible response bytes match the declared digest. Passing one check does not imply passing the other.

This separation is useful during incident diagnosis. A resource can fail because the digest is stale, because cross-origin response headers are unsuitable, because the network request failed, or because another browser policy blocked the load. Treating every SRI-related load failure as a hash problem can hide the actual boundary that rejected the response.

Multiple digests support controlled transitions

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

That capability can help with transitions, but it should not become an open-ended list of historical versions. Every accepted digest enlarges the set of bytes that can satisfy the element’s integrity condition. Old digests should remain only while their corresponding resource versions are intentionally valid for that reference.

Algorithm selection also matters. Browsers evaluate supported integrity algorithms according to SRI processing rules rather than treating an arbitrary collection of tokens as independent fallback strings. Deployment tooling should generate metadata consistently and verify the rendered HTML instead of relying on manual digest edits.

Mutable URLs require coordinated deployment

SRI fits most naturally when resource content is immutable or versioned. A URL such as /assets/app.8f31c2.js can be paired with integrity metadata that remains stable for the lifetime of that object. A mutable URL such as /assets/app.js requires tighter coordination because replacing its bytes invalidates documents that still carry the previous digest.

Caching can extend that coordination window. An older HTML document may reference an older digest while the mutable asset URL now serves a newer body. The resulting failure is correct from SRI’s perspective: the bytes no longer match the document’s declared expectation.

Content-addressed or fingerprinted asset names reduce this ambiguity. A new build can publish a new URL and new digest while older HTML continues to refer to the previous immutable object. SRI then acts as an additional byte check rather than as compensation for a mutable deployment contract.

Digest generation belongs in the build path

Manual integrity metadata is fragile for frequently changing assets. A safer release path derives the digest from the exact artifact being published, writes the resulting metadata into the generated HTML, and keeps the asset and document revisions coordinated.

The important input is the final resource bytes. Minification, bundling, banner insertion, newline conversion, or any other transformation performed after digest generation changes the object and invalidates the metadata. A pipeline should therefore compute the digest after transformations that affect the published representation.

Validation can also fetch or inspect the release artifact and compare its digest with the rendered page before promotion. That check catches stale metadata without weakening the browser-side enforcement.

SRI metadata itself should be protected by the normal integrity of the HTML delivery path. An attacker who can arbitrarily rewrite the document can also remove or replace its integrity attribute. SRI is therefore not a substitute for securing the origin that serves the page.

SRI does not evaluate resource intent

A matching digest proves a limited fact: the fetched bytes satisfy the integrity metadata selected by the browser. It does not establish that the code is free of vulnerabilities, that a dependency is trustworthy, or that its runtime behavior is appropriate for the application.

If an approved third-party script intentionally sends data to its operator, SRI does not block that behavior. If the pinned version contains a security defect, the correct digest faithfully permits that defective version. Dependency review, update policy, Content Security Policy, privilege boundaries, and application authorization remain separate controls.

SRI also does not provide revocation by itself. Removing a compromised digest from newly generated HTML affects documents that receive the updated markup; already cached documents and assets follow their own cache lifetimes and browser behavior. Incident procedures need to account for those delivery states.

The security boundary is exact content acceptance

Subresource Integrity is effective because its promise is specific. It lets a document state that an external script or stylesheet is acceptable only when its fetched bytes match declared cryptographic metadata.

That promise is strongest when asset URLs are immutable, digest generation is part of the release pipeline, cross-origin response policy is configured deliberately, and old accepted digests are removed when no longer needed. It remains a content-pinning mechanism rather than a general verdict on the safety of the code it admits.