The Cross-Origin-Opener-Policy response header provides a way for a document to request a new browsing context group to better isolate itself from other untrustworthy origins. Optionally, browsers can also choose to place top-level documents in a different process from documents without a matching Cross-Origin-Opener-Policy.
At least two types of attacks are possible when a document shares a browsing context group and process with cross-origin documents: 1) Cross-window attacks. For example, a malicious document may open a victim document in a new window and later navigate the window to a look-alike document to trick the user. 2) Process-wide attacks. Transient execution attacks like Spectre allow a malicious document to leak data from a victim document, if they share an OS process. In browsers with full Site Isolation and out-of-process iframes, it is possible to mitigate process-wide attacks by putting documents from different sites in different processes. Cross-window attacks are less severe than process-wide attacks, but still remain possible in such browsers. In browsers without out-of-process iframes, it is difficult to put cross-origin documents in a different process if they are in the same browsing context group, without breaking script interactions between same-origin popups and iframes. We want to give sites the ability to sever all references to other browsing contexts to mitigate cross-window attacks, and to make it easier for browsers without out-of-process iframes to load the victim document in a new OS process to mitigate process-wide attacks like Spectre.
Status in Chromium
Enabled by default (tracking bug) in:
- Chrome for desktop release 83
- Chrome for Android release 83
Consensus & Standardization
Intent to Prototype urlIntent to Prototype thread
Last updated on 2020-11-09