v135 · security

Signature-based Integrity

This feature provides web developers with a mechanism to verify the provenance of resources they depend upon, creating a technical foundation for trust in a site's dependencies. In short: servers can sign responses with a Ed25519 key pair, and web developers can require the user agent to verify the signature using a specific public key. This offers a helpful

concepts

  1. Signature SRI

    The raw flow: server signs the response with Ed25519, the page pins the public key in integrity, browser verifies.

  2. Detect a swapped CDN bundle

    The CDN-compromise use case the explainer leads with: an attacker mutates one byte of the bundle, the signature breaks, the script never runs.

  3. Integrity pipeline

    A three-stage view of how a signed-asset request flows — request, response headers, browser verification. Toggle “CDN tampers” to flip the verdict from OK to FAIL.

  4. Key manager

    Generate an Ed25519 key pair in-browser, sign a JavaScript resource, and produce the integrity="ed25519-…" attribute value. Tamper the content and verify — shows the full CDN operator workflow: keygen → sign → deploy → verify.

why it shipped

To protect themselves from code injection, developers can restrict themselves to loading script from certain URLs and certain `<script>` elements (through Content Security Policy), and to loading script whose content is well-known (through Subresource Integrity). These satisfy a large number of use case, but fail to satisfy others (particularly supply chain integrity for dynamic resources). Signatures reasonably address this hole, nicely complementing the existing mechanisms.

references