The HTTP Cross-Origin-Opener-Policy (COOP) response header allows a website to control whether a new top-level document, opened using Window.open() or by navigating to a new page, is opened in the same browsing context group (BCG) or in a new browsing context group.
When opened in a new BCG, any references between the new document and its opener are severed, and the new document may be process-isolated from its opener. This ensures that potential attackers can't open your documents with Window.open() and then use the returned value to access its global object, and thereby prevents a set of cross-origin attacks referred to as XS-Leaks.
It also means that any object opened by your document in a new BCG can't access it using window.opener. This allows you to have more control over references to a window than rel=noopener, which affects outgoing navigations but not documents opened with Window.open().
The behavior depends on the policies of both the new document and its opener, and whether the new document is opened following a navigation or using Window.open().
Cross-Origin-Opener-Policy: unsafe-none
Cross-Origin-Opener-Policy: same-origin-allow-popups
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Opener-Policy: noopener-allow-popups
unsafe-none
The document permits sharing its browsing context group with any other document, and may therefore be unsafe. It is used to opt-out a document from using COOP for process isolation. This is the default value.
On navigations, documents with unsafe-none will always open and be opened into a new BCG â unless the other document also has unsafe-none (or no COOP directive value).
Using Window.open(), documents with unsafe-none will always open documents with any other value into a new BCG. However documents with unsafe-none can be opened in the same BCG if the opener has the directive same-origin-allow-popups, noopener-allow-popups, or unsafe-none. A document with same-origin will always open a document with unsafe-none in a new BCG.
same-origin
The document permits loading into BCGs that use COOP and contain only same-origin documents. This is used to provide cross-origin isolation for a BCG.
Documents with same-origin will only open and be opened in the same BCG if both documents are same-origin and have the same-origin directive.
This is similar to same-origin directive, except that it allows the opening of documents using Window.open() in the same BCG if they have a COOP value of unsafe-none.
The directive is used to relax the same-origin restriction for integrations where a document needs the benefits of cross-origin isolation but also needs to open and retain a reference to trusted cross-origin documents. For example, when using a cross-origin service for OAuth or payments.
A document with this directive can open a document in the same BCG using Window.open() if it has a COOP value of unsafe-none. In this case it does not matter if the opened document is cross-site or same-site.
Otherwise documents with same-origin-allow-popups will only open and be opened in the same BCG if both documents are same-origin and have the same-origin-allow-popups directive.
Documents with this directive are always opened into a new BCG, except when opened by navigating from a document that also has noopener-allow-popups. It is used to support cases where there is a need to process-isolate same-origin documents.
This severs the connections between the new document and its opener, isolating the browsing context for the current document regardless of the opener document's origin. This ensures that the opener can't run scripts in opened documents and vice versa â even if they are same-origin.
On navigations, a document with this directive will always open other documents in a new BCG unless they are same-origin and have the directive noopener-allow-popups. Using Window.open(), a document with this directive will open documents in a new BCG unless they have unsafe-none, and in this case it does not matter if they are same-site or cross-site.
Generally you should set your policies such that only same-origin and trusted cross-origin resources that need to be able to script each other should be allowed to be opened in the same browser context group. Other resources should be cross-origin isolated in their own group.
The following sections show whether documents will be opened in the same BCG or a new BCG following a navigation or opening a window programmatically.
Note: The specification uses the term "popup" to refer to any document opened using Window.open(), whether it is a popup, tab, window, or other context.
When navigating between documents, the new document is opened in the same BCG if the two documents have "matching coop policies", and otherwise into a new BCG.
The policies match if either both documents have the policy unsafe-none, or if the policies are the same and the documents are same-origin.
The table below shows how this rule affects whether documents are opened in the same or a new BCG for the different directive values.
Opener (â) / Opened (â)unsafe-none same-origin-allow-popups same-origin noopener-allow-popups unsafe-none Same New New New same-origin-allow-popups New Same if same-origin New New same-origin New New Same if same-origin New noopener-allow-popups New New New Same if same-origin Opening with Window.open()
When opening a document using Window.open(), the new document is opened in a new BCG according to the following rules, which are evaluated in order:
noopener-allow-popups => open the new document in a new BCGunsafe-none and the opener document has COOP set to either same-origin-allow-popups or noopener-allow-popups => open the new document in the same BCGThe table below shows how these rules affect whether documents are opened in the same or a new BCG for the different directive values.
Opener (â) / Opened (â)unsafe-none same-origin-allow-popups same-origin noopener-allow-popups unsafe-none Same New New New same-origin-allow-popups Same Same if same-origin New New same-origin New New Same if same-origin New noopener-allow-popups Same New New New Examples Features that depend on cross-origin isolation
Certain features, such as access to SharedArrayBuffer objects or using Performance.now() with unthrottled timers, are only available if your document is cross-origin isolated.
To use these features in a document, you will need to set the COOP header to same-origin and the Cross-Origin-Embedder-Policy header to require-corp (or credentialless). In addition the feature must not be blocked by Permissions-Policy: cross-origin-isolated.
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
You can use the Window.crossOriginIsolated and WorkerGlobalScope.crossOriginIsolated properties to check if a document is cross-origin isolated, and hence whether or not the features are restricted:
const myWorker = new Worker("worker.js");
if (crossOriginIsolated) {
const buffer = new SharedArrayBuffer(16);
myWorker.postMessage(buffer);
} else {
const buffer = new ArrayBuffer(16);
myWorker.postMessage(buffer);
}
Consider a hypothetical origin example.com that has two very different applications on the same origin:
/chat that enables any user to contact any other user and send them messages./passwords that contains all of the user's passwords, across different services.The administrators of the "passwords" application would very much like to ensure that it can't be directly scripted by the "chat" app, which by its nature has a larger XSS surface. The "right way" to isolate these applications would be to host them on different origins, but in some cases that's not possible, and those two applications have to be on a single origin for historical, business, or branding reasons.
The Cross-Origin-Opener-Policy: noopener-allow-popups header can be used to ensure that a document can't be scripted by a document that opens it.
If example.com/passwords is served with noopener-allow-popups the WindowProxy returned by Window.open() will indicate that the windows is closed (Window.closed is true), so the opener can't script the passwords app:
const handle = window.open("example.com/passwords", "passwordTab");
if (windowProxy.closed) {
// The new window is closed so it can't be scripted.
}
Note that this alone is not considered a sufficient security measure. The site would also need to do the following:
HttpOnly.postMessage or BroadcastChannel on the more-sensitive app don't expose any sensitive information the any other same-origin app.RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3