Cross-Origin Opener Policy

Other windows shouldn't be able to reach into yours

A page that opens yours — or that yours opens — keeps a reference to your window, and may share an operating system process with it. Cross-Origin Opener Policy severs that link and isolates your origin. Report URI collects the reports so you can see whether a policy would affect anything on your site before you enforce it.

Start Free Trial Documentation →
What's at Stake

By default, the window that opened you is still holding on.

Browsers have always let documents keep a handle on one another across a navigation or a popup. A site that links to yours with target="_blank" retains a window.opener reference, and a popup you open can reach back the same way. That relationship also means the two documents can share a renderer process, which is precisely what makes speculative execution attacks worth attempting. Cross-Origin Opener Policy is how you opt out — though switching it on blind means finding out the hard way whether anything on your site relied on that relationship.

Retained References

Other documents keep a handle on your window

Any page that opens yours, or that yours opens, holds a live cross-origin window reference. It cannot read your DOM, but it can navigate you, count your frames and time your responses — the raw material for tabnabbing and cross-site leak techniques.

Shared Processes

Your origin shares memory with content you don't control

Without an opener policy the browser is free to keep related documents in one renderer process. Speculative execution flaws like Spectre are only exploitable where attacker code and victim data occupy the same address space, so process isolation removes the class rather than patching around it.

Locked Capabilities

Powerful APIs stay switched off until you isolate

Browsers gate SharedArrayBuffer, unthrottled high-resolution timers and precise memory measurement behind cross-origin isolation. Until your origin sets an opener policy those APIs remain unavailable, no matter what else your application does.

What COOP Reporting Does

See every opener relationship before you sever it

Report URI collects Cross-Origin Opener Policy reports directly from your visitors' browsers, so you know which windows your site actually interacts with — and whether any of them matter — before you enforce anything.

Violation Reporting

Every severed relationship, reported from the real browser

When your policy affects an opener relationship the browser sends a report describing what happened. You see the disposition, the effective policy that applied, and the kind of access that triggered it — a navigation into your origin, a navigation away from it, or a script reaching between an opener and the window it opened. Real visitor sessions, not a crawl.

Learn more about the Reporting API →
Safe Rollout

Test the policy in report-only before anything is enforced

Send Cross-Origin-Opener-Policy-Report-Only and the browser evaluates your policy, tells you what it would have done, and changes nothing. Payment popups, federated sign-in windows and third-party widgets carry on working while you find out which of them actually depend on an opener relationship. When the reports go quiet, you promote the header.

Learn more about COOP setup →
Cross-Origin Isolation

The first half of unlocking the powerful APIs

Cross-origin isolation requires an opener policy of same-origin and an embedder policy alongside it. Report URI collects reports for both, so you can run the two rollouts together and see which one is still holding you back from SharedArrayBuffer and precise timers.

Learn more about COEP Reports →
Get Started

Isolate your origin. Know before you enforce.

One header. No code. COOP reports start arriving from your first visitor.

Start Free Trial Talk to our team →

30-day free trial  ·  One header  ·  No code  ·  Cancel anytime

Detection

Every report tells you which relationship broke

COOP reports are not a single undifferentiated stream. The browser tells you precisely which kind of access your policy affected, so you can separate the popup flows that matter from the incidental references that don't.

Report type What it means
navigation-to-response A navigation into your document was placed in a new browsing context group
navigation-from-response A navigation away from your document was isolated by your policy
access-from-coop-page-to-openee Your page tried to reach a window it opened, and was blocked
access-from-coop-page-to-opener Your page tried to reach the window that opened it, and was blocked
access-to-coop-page-from-openee A window your page opened tried to reach back into it
access-to-coop-page-from-opener The window that opened your page tried to reach into it

This is the difference between “the policy broke something” and knowing exactly which window, on which page, doing what.

Architecture

One response header. No code. No crawlers.

Cross-Origin Opener Policy is a browser standard, and its reporting is built into the browser alongside it. The data comes from real sessions — including the authenticated flows, geo-targeted content and third-party popups a crawler would never reach.

Start in report-only and nothing changes for your visitors. Add the header, point it at your reporting endpoint, and reports begin arriving from your first visitor.

Minimal setup — report-only, nothing enforced
Cross-Origin-Opener-Policy-Report-Only: same-origin;
  report-to="default"

COOP delivers its reports over the Reporting API, so you will also need a Report-To group pointing at your Report URI endpoint. Your subdomain and the exact header are on your Setup page once you have an account.

No code added to your pages

No crawler simulating page loads

Report-only mode changes nothing while you evaluate

Your site's performance is unaffected

Catches opener relationships that only occur in real flows — checkout popups, federated sign-in, authenticated sessions

Cross-Origin Isolation

COOP, COEP, and the capabilities behind them

Browsers will only grant SharedArrayBuffer, unthrottled performance.now() and precise memory measurement to documents that are cross-origin isolated — and that state requires two headers, not one. Cross-Origin Opener Policy isolates your browsing context group; Cross-Origin Embedder Policy governs the resources you embed. You need both, and each surfaces a different set of findings on the way.

Running both rollouts in report-only at the same time is the fastest route through. Report URI collects reports for each, so you can tell at a glance which header is still blocking isolation and which of your dependencies needs attention first.

COEP Reports →
Scope

One layer in the stack. Here's how it fits.

Cross-Origin Opener Policy governs the relationship between your window and the windows around it. It does not control what your page is allowed to load, and it does not tell you what your scripts are doing — it is the process isolation layer, and it works alongside the rest.

COOP does Pairs with
Severs cross-origin opener relationships COEP for embedded resources — the other half of cross-origin isolation
Puts your origin in its own process CSP for load control — deciding what is allowed to execute at all
Reports what a policy would affect Policy Watch for header integrity — detecting when the policy itself changes
Unlocks isolation-gated browser APIs Script Watch for dependency visibility — knowing what runs in the process you just isolated

Together, these form the browser-native security layer that sits between your application and the code executing around it.