Cross-Origin Opener Policy Checker

Check a page's Cross-Origin-Opener-Policy, what it isolates it from, and what will break if you tighten it.

Passive public check

a2z.tools reads publicly visible information from the address you enter. It is a read-only request - nothing is submitted, changed or probed.

Address to check Reads the response headers of a public page.

What COOP does

When one page opens another with window.open, or a page is opened by a link with target="_blank", the two keep references to each other. The opener can reach window.opener; the opened page can reach back. Those references survive navigation and cross origins.

Cross-Origin-Opener-Policy severs that link. With same-origin, a page from another origin gets no usable handle on your window, and your page gets none on theirs.

What that prevents

Tabnabbing. A page you opened can navigate the tab it came from. A visitor clicks a link, reads something in the new tab, returns to the original - and finds a convincing login page that was swapped in behind them. rel="noopener" fixes this per link; COOP fixes it for the whole document, including links you forgot.
Cross-window probing. A retained reference allows counting frames and observing navigation timing, which has been used as a side channel to infer whether a visitor is logged in somewhere.
It is half of cross-origin isolation. Without COOP: same-origin a page can never be cross-origin isolated, so SharedArrayBuffer and high-resolution timers stay unavailable regardless of what else you set.

The three values

unsafe-none - the default. No isolation. References work in both directions.
same-origin-allow-popups - inbound references are severed, but popups you open keep theirs. This is the value OAuth and payment flows usually need, because they open a provider window and then talk to it. It is a deliberate middle setting, not a weaker one - though it is not enough for cross-origin isolation.
same-origin - full isolation in both directions, and the value isolation requires.

Rolling it out

COOP breaks cross-window communication, so the risk is concentrated in flows that depend on it - sign-in popups, payment providers, some analytics and chat widgets. Deploy Cross-Origin-Opener-Policy-Report-Only first, which reports what would have been severed without severing it, and check the reports before enforcing. If a genuine popup flow breaks, the answer is usually same-origin-allow-popups rather than abandoning the header.

COOP is per response, so it can be applied to the pages that need it before the whole site. An account area can have same-origin while a marketing page does not.

Check the other half with Cross-Origin-Embedder-Policy Checker, and generate a compatible set with Cross-Origin Policy Generator.

Frequently asked questions

Do I still need rel="noopener" on links?

Modern browsers apply noopener to target="_blank" by default, and COOP: same-origin covers the whole document regardless. Keeping it explicitly is harmless and helps older browsers, but it is no longer the primary defence.

Will COOP break my OAuth sign-in popup?

same-origin will, because the flow depends on the popup and opener talking to each other. Use same-origin-allow-popups, which severs inbound references while preserving the ones you opened.

Is an unrecognised value dangerous?

It is worse than useless. Browsers ignore a value they do not recognise and fall back to unsafe-none, so a typo silently removes the protection while the header still appears to be set. This tool reports that case specifically.

Do I need COOP if I do not use SharedArrayBuffer?

Yes, for the tabnabbing and cross-window protection, which apply to every site. Cross-origin isolation is an additional benefit rather than the reason to set it.

References

Related tools

What this tool can and cannot tell you. It reports the configuration a site exposes to an ordinary visitor. It does not log in, submit anything, or test for vulnerabilities, so a passing result means the public configuration looked correct at the moment of the check - not that the site is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.