What Subresource Integrity verifies—and how to deploy it
SRI checks expected resource content. Hash selection, CORS permissions and coordinated updates determine whether that check can succeed.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
SRI verifies whether a fetched resource matches expected content; CORS determines whether a cross-origin response is eligible for that check.
Conceptual illustration; no actual digest or measured result is shown.
Expected content is the starting point
Subresource Integrity gives a browser an expected digest for a script or stylesheet. A response that fails the applicable comparison is rejected for that resource. This helps detect a changed file, but the result does not explain why it changed: a normal release can also invalidate old metadata. The question is whether the fetched content matches the declared expectation, rather than whether a security incident has been proven.
The containing document remains part of the trust boundary. If an attacker can replace both a resource and its expected digest, the comparison no longer preserves the author’s original expectation. Matching content can still contain undesirable code. This is a consequence of checking content identity, not an assessment of the code’s purpose. Expected-content boundary
Read the algorithm and the selected set
An integrity expression names an algorithm and a Base64 digest. Verification selects the strongest recognized algorithm represented, then accepts any matching digest within that set. A weaker match cannot rescue a stronger-set mismatch. SHA-384 is a baseline choice discussed in the 2016 Recommendation, not the only permitted algorithm. Selection rule
Read a multi-value attribute as a set of expectations rather than a list of approvals from different publishers. In an illustrative release, two values could represent two accepted files. Before copying such an attribute, ask which file each value represents and why both should remain acceptable. If that relationship is unknown, the extra value makes the release harder to explain. This is a hypothetical documentation exercise; it supplies no usable digest and no result from testing a real browser.
Separate origin permission from integrity
Same-origin responses can be eligible for the check; cross-origin responses need CORS access. Adding an integrity attribute does not grant that access. The element’s crossorigin setting and the server’s response permissions must agree. For a classic script fetched without a CORS mode, merely copying a digest into HTML is insufficient for cross-origin SRI. Module scripts already have their own CORS requirements. Script element
MDN distinguishes anonymous from use-credentials. Anonymous does not send credentials to a different origin; use-credentials requests them. Credentialed CORS requires an explicit allowed origin and permission for credentials, rather than a wildcard allowed-origin value. Credentialed CORS Therefore crossorigin="anonymous" is a common configuration, not the only conceivable credential mode. Check the actual request and response instead of treating one pasted attribute as proof of permission. Credential modes
Treat a release as a coordinated change
Consider an illustrative deployment that updates a library while a page retains its earlier digest. The new resource can be rejected even when both versions were intentionally produced. Conversely, publishing new metadata while a cache still serves the old representation can produce the same mismatch. Neither observation alone establishes malicious modification.
The comparison concerns representation data, with content codings handled by the specification’s algorithm; it is not a promise about a particular browser’s memory buffer or raw compressed network bytes. Identify the final resource being distributed and keep its digest aligned with the page. A fixed digest needs coordinated updates when content changes. Frequent changes create a maintenance problem, rather than making integrity checking structurally impossible. Representation and deployment
An institutional expert perspective on limits
MDN’s specialist documentation is useful as a deployment checklist: identify the element and URL, its integrity metadata, the request’s origin and credential mode, and the server’s CORS response. Test a valid resource and a deliberate mismatch separately. A failed script may affect dependent page behavior, but the specification rejects the affected resource; it does not guarantee that every client or the entire application fails.
Plan an appropriate failure or fallback path without assuming that manual digest generation is inherently invalid or that a named build tool is mandatory. SRI is one bounded check in a deployment. Its protection depends on trusted expectations and eligible responses, while code review and other controls address different questions. The stable rules here are grounded in the dated 2016 Recommendation; the latest W3C URL read for this packet was a 2026 Working Draft, not evidence that every new feature is implemented. Draft status MDN deployment guidance