Skip to content

CONCEPT Cited by 1 source

Same-origin dictionary scope

Same-origin dictionary scope is the constraint — enforced by RFC 9842 — that a compression dictionary served by origin A is only usable to compress responses from origin A. A browser cannot use a dictionary fetched from example.com to decode a response from cdn.example.net or from any third party.

Canonical framing: this is the single design choice that lets RFC 9842 ship where SDCH was un-shipped.

Why it matters

SDCH (2008-2017) allowed cross-origin dictionary reuse — a single dictionary could be served from a CDN-like origin and reused across many sites. That design ironically powered SDCH's performance (lots of sites sharing common dictionaries got cross-the-board compression wins) but created two systemic problems:

  1. Violated the Same-Origin Policy — content fetched from origin B (the dictionary) was being stitched into responses from origin A (the sensitive resource). Browser security model didn't allow this for good reason.
  2. Couldn't be reconciled with CORS — the dictionary-lifecycle couldn't be retrofit with Access-Control-Allow-Origin checks while preserving the compression-ratio wins that justified the model.
  3. Enabled compression side-channel attacks — cross-origin dictionaries meant an attacker could influence a dictionary fetched from an origin they controlled and have it compress a victim's sensitive responses. CRIME/BREACH-class attacks extended cleanly into this model.

RFC 9842 makes the opposite design choice: dictionaries are same-origin-only. The performance ceiling is lower (no cross-site dictionary reuse) but the security + interop story is clean:

  • Same-Origin Policy is trivially satisfied.
  • No CORS mechanism needed.
  • Most of the cross-origin CRIME/BREACH- class attack surface is closed.
  • Browser implementers (Chrome, Edge, Firefox-in-progress) can reason about dictionary lifecycle in isolation per origin.

Residual risks (what's still possible)

Same-origin dictionary scope does not eliminate compression side channels entirely. It closes the cross-origin surface, not the same-origin one. Classic BREACH — attacker-controlled content injected into the same origin's sensitive response — remains possible even with RFC 9842, because the dictionary constraint doesn't prevent compression-side-channel oracles within a single origin.

The classical defenses (disable compression on sensitive endpoints, randomise response length, separate compression contexts) still apply to the residual surface.

Operational consequence

Each origin owns its own dictionary lineage. Sub-origins (api.example.com vs cdn.example.com) have independent dictionaries; requesting the same asset-class URL on a sibling origin does not leverage the dictionary cached from the first origin. Customers with multi-origin deployments may see lower aggregate compression wins than they would on a consolidated single-origin architecture.

Seen in

Last updated · 200 distilled / 1,178 read