Cross-Origin-Opener-Policy-Report-Only

Deploying a strict Cross-Origin-Opener-Policy severs cross-origin window references, breaking OAuth popups and payment redirects. The HTTP Cross-Origin-Opener-Policy-Report-Only response header tests COOP in observation mode, sending violation reports to a designated endpoint without breaking those references.

Table of Contents

Usage

Deploying a strict Cross-Origin-Opener-Policy (COOP) changes how a page interacts with cross-origin popups and opener windows. Setting same-origin on the enforcing header severs the window.opener reference for any cross-origin window, which breaks legitimate workflows like OAuth popups and payment redirects.

The Cross-Origin-Opener-Policy-Report-Only header applies the same policy logic in observation mode. The browser evaluates every cross-origin window interaction against the declared policy and generates a report for each violation, but keeps the window references intact. Reports are sent to the endpoint named in the report-to directive, which maps to a URL declared in the Reporting-Endpoints or Report-To header.

This report-only approach allows operators to measure the impact of a COOP policy before committing to enforcement. Once the violation reports confirm there are no unexpected breakages, the policy moves to the enforcing Cross-Origin-Opener-Policy header.

Directives

unsafe-none

The unsafe-none directive is the default behavior. No cross-origin opener restrictions are applied, and no violation reports are generated. This is the baseline before any COOP policy is introduced.

same-origin-allow-popups

The same-origin-allow-popups directive reports violations when a cross-origin document opens the page, but allows the page itself to open cross-origin popups and retain a reference to them. This is the common first step for sites relying on OAuth or payment popups.

same-origin

The same-origin directive reports violations for any cross-origin window relationship. Both popups opened by the page and windows opening the page generate violation reports when their origins differ.

restrict-properties

The restrict-properties directive was proposed to enable cross-origin isolation while still permitting popup interaction. Unlike same-origin, the proposed directive does not fully sever the opener relationship with cross-origin popups. Instead, the proposal restricts which properties are accessible on the cross-origin window. Chrome put the proposal on hold in April 2025 after its origin trial ended, and no browser ships the directive.

When a page has both COOP: same-origin and a compatible Cross-Origin-Embedder-Policy enforced, the HTML spec internally tracks this combined state as same-origin-plus-COEP. This term is an internal computed value in the specification and is not a directly settable header value. Setting same-origin paired with an enforcing COEP produces that state.

report-to

The report-to directive specifies the name of the reporting endpoint group receiving COOP violation reports. The name maps to an endpoint declared in the Reporting-Endpoints or Report-To response header. Without this directive, violations are observed but no reports are sent.

Example

A same-origin policy in report-only mode sends violation reports to an endpoint named coop-endpoint. The browser evaluates all cross-origin window interactions against the same-origin policy and reports violations to the URL mapped to coop-endpoint in the Reporting-Endpoints header, without severing any window references.

Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop-endpoint"
Reporting-Endpoints: coop-endpoint="https://reports.example.re/coop"

A same-origin-allow-popups policy in report-only mode catches cases where a cross-origin document opens the page, while still allowing the page to open popups freely. Reports go to the wsp_coop endpoint.

Cross-Origin-Opener-Policy-Report-Only: same-origin-allow-popups; report-to="wsp_coop"
Reporting-Endpoints: wsp_coop="https://reports.example.re/wsp-coop"

An unsafe-none report-only value paired with a report-to directive monitors the current state before tightening the policy. The browser reports nothing in this configuration because unsafe-none matches the default behavior. Sites use this as a canary to verify the reporting pipeline works before switching to a stricter policy value.

Cross-Origin-Opener-Policy-Report-Only: unsafe-none; report-to="default"
Reporting-Endpoints: default="https://reports.example.re/default"

The rollout pairing, and the one-browser reality

Report-only COOP holds a capability its enforcing form lacks during staged rollouts: evaluated together with report-only COEP, the pair computes the full cross-origin-isolation posture, so reports describe what enforcement will do before either header changes behavior. A workable rollout starts here, report-only COOP first, then report-only COEP, with enforcement last and crossOriginIsolated checked only after the switch. The specification leaves the deployment order free, so teams pick the sequence fitting their risk.

Reports arrive under the coop type with subtypes separating navigation violations from opener-access violations, and access reports name the exact JavaScript property touched, with source file and line, which turns a vague isolation break into a pointed diff.

Delivery is Chromium-only in practice. The report-to parameter ships in Chromium, the Firefox implementation bugs remain open years after filing, Safari ships nothing, and the header is absent from MDN and the compatibility data entirely, despite every sibling report-only header being documented. A quiet report stream therefore describes Chrome users alone, and the header's observability gap is itself worth knowing: deployment surveys measure enforced COOP and leave the report-only variant uncounted.

See also

Last updated: August 17, 2026