The HTTPCross-Origin-Opener-Policy (COOP)response header allows a website to control whether a new top-level document, opened usingWindow.open() or by navigating to a new page, is opened in the samebrowsing 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 withWindow.open() and then use the returned value to access its global object, and thereby prevents a set of cross-origin attacks referred to asXS-Leaks.

It also means that any object opened by your document in a new BCG can't access it usingwindow.opener.This allows you to have more control over references to a window thanrel=noopener, which affects outgoing navigations but not documents opened withWindow.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 usingWindow.open().

Syntax

Cross-Origin-Opener-Policy: unsafe-noneCross-Origin-Opener-Policy: same-origin-allow-popupsCross-Origin-Opener-Policy: same-originCross-Origin-Opener-Policy: noopener-allow-popups

Directives

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 withunsafe-none will always open and be opened into a new BCG — unless the other document also hasunsafe-none (or no COOP directive value).

UsingWindow.open(), documents withunsafe-none will always open documents with any other value into a new BCG.However documents withunsafe-none can be opened in the same BCG if the opener has the directivesame-origin-allow-popups,noopener-allow-popups, orunsafe-none.A document withsame-origin will always open a document withunsafe-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 providecross-origin isolation for a BCG.

Documents withsame-origin will only open and be opened in the same BCG if both documents are same-origin and have thesame-origin directive.

same-origin-allow-popups

This is similar tosame-origin directive, except that it allows the opening of documents usingWindow.open() in the same BCG if they have a COOP value ofunsafe-none.

The directive is used to relax thesame-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 usingWindow.open() if it has a COOP value ofunsafe-none.In this case it does not matter if the opened document is cross-site or same-site.

Otherwise documents withsame-origin-allow-popups will only open and be opened in the same BCG if both documents are same-origin and have thesame-origin-allow-popups directive.

noopener-allow-popups

Documents with this directive are always opened into a new BCG, except when opened by navigating from a document that also hasnoopener-allow-popups.It is used to support cases where there is a need to process-isolatesame-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 directivenoopener-allow-popups.UsingWindow.open(), a document with this directive will open documents in a new BCG unless they haveunsafe-none, and in this case it does not matter if they are same-site or cross-site.

Description

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.

Navigations

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 policyunsafe-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.

Opening with Window.open()

When opening a document usingWindow.open(), the new document is opened in a new BCG according to the following rules, which are evaluated in order:

1. If the new document has COOP set tonoopener-allow-popups => open the new document in a new BCG
2. If the new document has COOP set tounsafe-none and the opener document has COOP set to eithersame-origin-allow-popups ornoopener-allow-popups => open the new document in the same BCG
3. If the new document and the opening document havematching COOP policies => open the new document in the same BCG
4. Otherwise, open the new document in a new BCG

The table below shows how these rules affect whether documents are opened in the same or a new BCG for the different directive values.

Examples

Features that depend on cross-origin isolation

Certain features, such as access toSharedArrayBuffer objects or usingPerformance.now() with unthrottled timers, are only available if your document iscross-origin isolated.

To use these features in a document, you will need to set the COOP header tosame-origin and theCross-Origin-Embedder-Policy header torequire-corp (orcredentialless).In addition the feature must not be blocked byPermissions-Policy: cross-origin-isolated.

Cross-Origin-Opener-Policy: same-originCross-Origin-Embedder-Policy: require-corp

You can use theWindow.crossOriginIsolated andWorkerGlobalScope.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);}

Severing the opener relationship

Consider a hypothetical originexample.com that has two very different applications on the same origin:

• A chat application at/chat that enables any user to contact any other user and send them messages.
• A password management application at/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.

TheCross-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.

Ifexample.com/passwords is served withnoopener-allow-popups theWindowProxy returned byWindow.open() will indicate that the windows is closed (Window.closed istrue), 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:

• Use Fetch Metadata to block same-origin requests to the more-sensitive app that are not navigation requests.
• Ensure their authentication cookies are allHttpOnly.
• Ensure root-level Service-Workers are not installed by the less-sensitive app.
• Ensure thatpostMessage orBroadcastChannel on the more-sensitive app don't expose any sensitive information the any other same-origin app.
• Ensure their login page is served on a separate origin, due to password manager autofill being applied based on origin.
• Understand that the browser may still allocate the more-sensitive app in the same process as the less-sensitive one, making it vulnerable to Spectre-like attacks.

Specifications

Browser compatibility

See also

• Cross-Origin-Embedder-Policy