Cross-Origin-Opener-Policy

TL;DR: Isolates your browsing context from cross-origin documents to prevent Spectre-like attacks. Use same-origin with COEP to enable cross-origin isolation and unlock SharedArrayBuffer.

What is Cross-Origin-Opener-Policy?

The Cross-Origin-Opener-Policy (COOP) header controls whether your top-level document shares a browsing context group with other documents.

When tightened, COOP isolates your window from cross-origin pages and reduces attack surface for side-channel and cross-window abuse.

Syntax

Cross-Origin-Opener-Policy: unsafe-none
Cross-Origin-Opener-Policy: same-origin-allow-popups
Cross-Origin-Opener-Policy: same-origin
```text

## Value Guide

- `unsafe-none`: default browser behavior, no isolation
- `same-origin-allow-popups`: isolates your document but allows opener relationship for popups you create
- `same-origin`: strict isolation from cross-origin documents

## Example

```http
HTTP/1.1 200 OK
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

This pairing is commonly used to enable crossOriginIsolated, which is required for features like SharedArrayBuffer in modern browsers.

Implementation

app.use((req, res, next) => {
  res.setHeader('Cross-Origin-Opener-Policy', 'same-origin')
  next()
})

Operational Impact

Tight COOP can change popup/window behavior:

• window.opener relationships may be severed
• Some legacy OAuth/payment popup flows can break
• Cross-window scripting assumptions stop working

Roll out gradually and test critical auth flows.

COOP, COEP, and CORP Together

• COOP isolates browsing contexts
• Cross-Origin-Embedder-Policy controls embeddable cross-origin resources
• Cross-Origin-Resource-Policy controls resource-level embedding policy

You usually need all three aligned for strong cross-origin isolation.

Related Headers

• Cross-Origin-Embedder-Policy
• Cross-Origin-Resource-Policy

COOP and Cross-Origin Isolation

Cross-Origin-Opener-Policy is one half of the cross-origin isolation requirement. To achieve a crossOriginIsolated environment — which unlocks SharedArrayBuffer, high-resolution timers, and performance.measureUserAgentSpecificMemory() — a page must set both Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp.

The reason both headers are required is that they address different attack surfaces. COOP prevents a cross-origin page from gaining a reference to your window via window.opener or window.open(), which could be used to read timing information through side channels. COEP ensures that every resource embedded in your page has explicitly opted in to being embedded cross-origin, preventing data exfiltration through embedded resources.

The practical impact of same-origin COOP is that it breaks any feature that relies on cross-window communication with cross-origin pages. OAuth popup flows are the most common casualty: the popup opens the identity provider’s login page, and after authentication, the provider calls window.opener.postMessage() to send the token back. With COOP set to same-origin, the opener reference is null in the popup, so postMessage fails silently.

The workaround for OAuth is to use same-origin-allow-popups instead of same-origin. This value isolates your page from cross-origin pages that open it, while still allowing popups that your page opens to communicate back via postMessage. It provides most of the security benefit of same-origin while preserving OAuth popup flows. For full cross-origin isolation, you need same-origin, which means migrating OAuth flows to redirect-based rather than popup-based patterns.