Eiji Kitamura recently addressed in a talk at Google’s web.dev live the new COOP and COEP policies that dictate how browsers handle cross-origin resources. The new opener (COOP) and embedded (COEP) policies set up a cross-origin isolated environment that protects against Spectre attacks while restoring powerful, previously disabled features (SharedArrayMemoryBuffer and more).
Kitamura explained the motivation behind the new policies:
Some web APIs increase the risk of side-channel attacks like Spectre. To mitigate that risk, browsers offer an opt-in-based isolated environment called cross-origin isolated. With a cross-origin isolated state, the webpage will be able to use privileged features including:
SharedArrayBuffer
(required for WebAssembly Threads)performance.measureMemory()
- JS Self-Profiling API
The new policies thus enable developers to use shared memory across threads and high-resolution timers that were effectively disabled at the start of 2018 in light of Spectre.
For top-level documents, developers will need to set two headers to cross-origin isolate their site and enable the aforementioned privileged features:
Cross-Origin-Opener-Policy (COOP)
withsame-origin
as value (protects the origin from attackers)Cross-Origin-Embedder-Policy (COEP)
withrequire-corp
as value (protects victims from the origin)
A crossOriginIsolated property will be available in the window
and worker
scopes (currently implemented only in Firefox):
if (crossOriginIsolated) {
// Post SharedArrayBuffer
} else {
// Do something else
}
The new policies can be used in the Chrome and Firefox desktop browsers, while shared memory across workers will continue to be disabled in Safari in the near future.
COOP allows a top-level document to break the association between its window and any others in the browsing context group (e.g. between a popup and its opener). Doing so prevents direct DOM access between windows in different browsing contexts.
On every top-level navigation, the browser compares the value of the Cross-Origin-Opener-Policy
header between the document which initiated the navigation (by following a link or opening a popup) and the target of the navigation. If at least one of the documents sets COOP, then if the COOP values of the documents are not the same, or the origins of the documents do not match, the browser will sever the link between the documents by creating a new browsing context group. This prevents process-wide attacks (e.g., Spectre), cross-window attacks and other side-channel attacks.
Kitamura explains:
When Cross-Origin-Opener-Policy same-origin is set, any cross-origin window opened from the document will have no access to the opener’s DOM, so window.opener will return null.
This is how the document achieves isolation from the cross-origin window.
COEP ensures that a document can only load resources that explicitly grant permission to be loaded by setting the right CORP or CORS headers. Requiring COEP to be set on iframes recursively propagates resource loading restrictions to all descendent contexts.
(Source: web.dev)
As the new cross-origin policy options are gradually adopted, Kitamura encouraged CDN owners to more largely deploy CORP on their servers and linked to an CORP explainer:
Over time, browsers will begin requiring pages to opt-into cross-origin isolation […]. With this in mind, it seems likely that usage of
Cross-Origin-Embedder-Policy
will increase over time, and therefore thatCross-Origin-Resource-Policy
will be important to consider when configuring your server.
Kitamura further discusses the links between the new COEP and COOP policies and the existing ones (e.g., CORS, or CORP). The full talk, available online, includes abundant explanations and illustrations about the motivation and behaviors linked to cross-origin isolation.
web.dev LIVE is a Google-sponsored three-day online community event addressing the state of web development. The 2020 edition of the event took place at the end of June. All recorded sessions are already available.