Wiki · Concept · Last reviewed June 25, 2026

Subresource Integrity

Subresource Integrity is a W3C browser security mechanism for verifying that a fetched script, stylesheet, or other eligible subresource matches integrity metadata supplied by the page.

Category: Concept Updated: June 25, 2026 Tags: browser security, supply chain, CSP, agents, web governance

Definition

Subresource Integrity, usually shortened to SRI, is defined in the W3C Subresource Integrity Working Draft dated March 20, 2026. The draft gives browsers a way to check whether fetched resources match the bytes the page expected. The practical object is modest: when a page asks the browser to fetch code or styling from a URL, the page can also provide integrity metadata that describes the bytes it expects to receive.

SRI matters because modern web pages often include scripts and styles from content delivery networks, analytics providers, design systems, advertising stacks, experimentation tools, and embedded service vendors. Without an integrity check, the page is delegating execution to whatever arrives from that remote resource at load time. With SRI, the browser can compare the fetched bytes against a cryptographic digest before it executes or applies the resource.

Mechanism

The central mechanism is the integrity attribute on resource-loading elements such as script and link. Its value is integrity metadata: a hash algorithm token, a dash, and a base64-encoded digest. The W3C draft names SHA-256, SHA-384, and SHA-512 as the valid SRI hash algorithm token set. It also describes algorithm agility, so user agents can deprecate weak hash functions and authors can migrate to stronger functions over time.

When the browser fetches a resource with integrity metadata, it computes the digest of the received bytes and checks whether the result matches the supplied metadata. If it does not match, the resource is not accepted for that load. This turns an otherwise open-ended reference to a remote file into a reference to a particular byte sequence.

The draft also ties SRI use to CORS, treating a non-CORS SRI configuration as invalid. That boundary matters for privacy: integrity checks should not become a way for one origin to learn details about a protected cross-origin response by testing candidate hashes. In review, SRI and CORS evidence should be read together, not as separate checkboxes.

The 2026 draft also defines an enforcement layer through Integrity-Policy and Integrity-Policy-Report-Only headers. These headers can express that certain destination types, currently including script and style, should require integrity metadata. In report-only mode, a site can observe missing-integrity cases before blocking them.

Agent Context

For AI Browsers and Computer Use, SRI is a supply-chain control around the web page the agent inhabits. A browser agent may follow instructions inside an application whose behavior depends on third-party scripts, remote widgets, or model-generated HTML previews. SRI cannot tell the agent what to believe, but it can reduce one class of ambient surprise: a known external script or stylesheet silently changing between review and runtime.

SRI also complements Content Security Policy. CSP Level 3 includes algorithms for checking whether integrity metadata matches a policy source list, while leaving byte-level SRI validation to the SRI mechanism itself. In practice, a review should ask both questions: is the page allowed to load this class of resource, and did the fetched resource match the expected integrity metadata?

Governance Use

The governance value is reproducibility. A procurement reviewer, red team, or incident responder can compare a declared hash, a resource URL, a release artifact, and a browser violation. This is useful when a system includes vendor-hosted JavaScript, customer-facing agent workspaces, embedded payment flows, identity widgets, or dashboards that receive model output.

A mature record should preserve the page URL, resource URL, integrity value, hash algorithm, CORS mode, response status, final redirected URL, enforcement mode, violation report, application release, and the user or agent action that triggered the load. If a site uses Integrity-Policy, the record should also include blocked destinations and reporting endpoints.

Limits

SRI is not a general trust system. It does not prove that the resource is benevolent, audited, accessible, privacy-preserving, or appropriate for an agentic workflow. It proves only that a fetched resource matched supplied integrity metadata under the browser behavior being reviewed.

It also does not help if the attacker can alter the document that carries the resource URL and its hash. The W3C draft notes that an attacker able to modify the document can alter the integrity metadata just as they can alter the protected response. SRI therefore belongs beside server security, build provenance, CSP, least-privilege embedding, and reviewable deployment pipelines.

Review Record

Source Discipline

Claims about SRI should cite the exact W3C draft or browser implementation being evaluated, because the 2026 Integrity-Policy layer is still a Working Draft feature. For live systems, pair standards citations with observed headers, browser versions, fetch logs, and violation reports.

Spiralist Reading

Spiralism reads SRI as a covenant with bytes, not with brands. A familiar domain, a polished widget, or a trusted vendor name is not the same as the thing that actually arrives in the browser. The humane pattern is to make delegation specific: this resource, from this release, with this digest, under this policy, at this moment.

Sources

Return to Wiki