A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

[Proposal] Cross-Origin-Embedder-Policy



Explainer: https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit

Spec: https://mikewest.github.io/corpp/ (monkey patching HTML and Fetch; intended to be folded back into those specifications)

The same-origin policy’s restrictions against direct access to another origin’s resources is, unfortunately, insufficient in the face of speculative execution attacks like Spectre. Merely loading another origins’ resource may be enough to bring its content into a memory space which may be probed by an attacker, even if the browser would otherwise prevent access to the resource through explicit channels.

Given this context, user agents are rethinking the threat model under which they operate (e.g. [chromium-post-spectre-rethink]). It would be unfortunate indeed to prevent the web platform from legitimately using APIs like SharedArrayBuffer that accidentally improve attackers’ ability to exploit speculation attacks, but at the same time, many user agents have agreed that it seems unreasonable to enable those APIs without additional mitigation.

Cross-Origin-Embedder-Policy tackles one piece of the broader problem by giving developers the ability to require an explicit opt-in from any resource which would be embedded in a given context. User agents can make that requirement a precondition for some APIs that might otherwise leak data about cross-origin resources, which goes some way towards ensuring that any leakage is voluntary, not accidental.

To that end, the proposal does three things:

  1. It introduces a new cross-origin value for the Cross-Origin-Resource-Policy HTTP response header, which constitutes an explicit declaration that a given resource may be embedded in cross-origin contexts.

  2. It introduces a new Cross-Origin-Embedder-Policy header which shifts the default behavior for resources loaded in a given context to an opt-in model, in which cross-origin responses must either assert a Cross-Origin-Resource-Policy header which allows the embedding, or pass a CORS check.

  3. It extends Cross-Origin-Resource-Policy to handle some navigation requests in order to deal reasonably with iframe embeddings and window.open() .

Together, these would allow a user agent to gate access to interesting APIs on a top-level context opting-into Cross-Origin-Embedder-Policy, which in turn gives servers the ability to inspect incoming requests and make reasonable decisions about when to allow an embedding.

This mechanism is implemented behind a flag in both Chrome and Firefox. An intent to ship is out for the former, and the latter has announced their intent to do the same via https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/Planned_changes. I hope that level of interest justifies adopting the monkey-patch spec into WICG.


Given the support from Mozilla, seems safe to move this to WICG for further incubation.


Repo now lives at https://github.com/WICG/cross-origin-embedder-policy