No Cross-Origin-Opener-Policy is in force
Updated
What this check looks for
Windows your site opens, and windows that open your site, can still reach into each other. A Cross-Origin-Opener-Policy of same-origin separates them.
Why it matters
Nothing is wrong. It is recorded because Cross-Origin-Opener-Policy: same-origin is a small change that removes a class of cross-window attacks, and because it is half of what a page needs to use the high-precision timers modern APIs require.
When the check passes, your report says: “A Cross-Origin-Opener-Policy isolates this page's window”.
What it costs your score
This check never deducts. It reports a fact — or reports that something could not be verified — and is shown on the report without moving the score.
- Severity
- info
- Default confidence
- confirmed
- Status when triggered
- info
- Deduction
- 0 points
- Family cap
- none
- Category
- Web security
- Module
- Web security headers
- Fix owned by
- user
- In the ruleset since
- 2026.09
How to fix it
Send Cross-Origin-Opener-Policy: same-origin, or same-origin-allow-popups where a popup flow needs it.
It cuts the window references cross-site leak attacks rely on, at almost no cost to an ordinary site.
List the flows that open, or are opened by, another site's window: social sign-in, payment providers, document previews.
If none of them relies on
window.opener, sendsame-origin.If your page opens such a popup and expects a message back, send
same-origin-allow-popupsinstead — a deliberate choice that keeps the link only for popups you open.If other sites open your page in a popup and expect it to reach back — you are the sign-in provider — leave the header off those pages deliberately, and send it everywhere else.
How to confirm it worked
curl -sSI https://‹host›/ | grep -i cross-origin-opener-policy — expect same-origin or same-origin-allow-popups
Run your sign-in and checkout flows end to end after the change.
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
‹detail›
same-origin severs the window.opener relationship with cross-origin documents. It is a prerequisite, with Cross-Origin-Embedder-Policy, for cross-origin isolation and therefore for SharedArrayBuffer and performance.measureUserAgentSpecificMemory(). Check any OAuth or payment popup flow before enabling it — those rely on window.opener.
Without the header, a page opened in a popup or a new tab keeps a live reference to the window that opened it, and the opener keeps one to it. Across origins that reference is narrow, but it is enough to send the other window somewhere else and to observe things about it, such as how many frames it holds — the raw material of cross-site leak attacks — and it lets the browser keep both pages in one browsing context group.
The values: same-origin cuts the link with every cross-origin window, in both directions; same-origin-allow-popups keeps it for popups your page opens itself, which is what a sign-in or payment popup that reports back through window.opener needs; noopener-allow-popups also cuts the link with same-origin openers, and is newer and less widely supported; unsafe-none is the browser default written out and isolates nothing. A value browsers do not recognise falls back to unsafe-none, so this check reports unsafe-none and an unrecognised value exactly as it reports a missing header. The value is compared exactly, so Same-Origin is unrecognised, and a header sent twice — even twice with the same value — reaches the browser as a list it cannot read as one policy, so it falls back too. Our security headers generator writes same-origin.
To see what would break before committing, send Cross-Origin-Opener-Policy-Report-Only with a reporting endpoint first. In the browser console, self.crossOriginIsolated returns true only once this header and a Cross-Origin-Embedder-Policy are both in force.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.