REF-071: W3C Subresource Integrity

REF-071: W3C Subresource Integrity

Citation

W3C Web Application Security Working Group. (2026). Subresource Integrity. W3C Working Draft. https://www.w3.org/TR/sri-2/

W3C. (2016). Subresource Integrity becomes a W3C Recommendation. https://www.w3.org/blog/2016/06/subresource-integrity-becomes-a-w3c-recommendation/

Document Profile

AttributeValue
Year2016-2026
TypeWeb security specification
StatusSRI 1 Recommendation; SRI 2 active draft
GRADE / QualityA - W3C standardization track and deployed browser security primitive
AIWG RelevanceHigh - Direct precedent for hash-verifying fetched web resources

Executive Summary

Subresource Integrity lets a client verify that fetched web content matches a declared cryptographic hash before using it. It was designed for browser-loaded scripts and styles, but the underlying rule generalizes to AIWG web resources: remote bytes are not trusted merely because HTTPS delivered them.

AIWG's release manifest and descriptor checks apply the same fail-closed principle to framework resources, prebuilt indices, and raw `show` bodies.

AIWG Implementation Mapping

SRI ConceptAIWG Resource Implication
Integrity metadata accompanies a URLManifest descriptors accompany every resource path
Hash mismatch blocks useDigest mismatch fails the CLI command
CDN safety modelRelease host/cache safety model
Cross-origin resource riskWeb-backed first-party corpus risk

Design Implications

  • Treat digest mismatches as security failures, not cache misses.
  • Keep the expected digest outside the fetched body being verified.
  • Do not add an operator flag that disables signature or digest verification.

Cross-References

  • REF-068: npm lockfiles include integrity fields for package fetches.
  • REF-072: TUF extends integrity checks with metadata roles, expiry, threshold

signing, and rollback protections.

  • `docs/install/web-backed-resources.md`: AIWG trust and local override policy.