Use Cross-Origin-Opener-Policy: same-origin-allow-popups when your page wants isolation but must keep a reference to a trusted cross-origin popup, such as an OAuth sign-in or a payment window. The stricter same-origin value severs that link and can break the popup flow.
Why popups break under same-origin
With same-origin, a document only shares a browsing context group with documents that are same-origin and also set same-origin. A sign-in provider's popup is cross-origin and usually sends no COOP header at all, which means unsafe-none. Under same-origin, the browser opens that popup in a new group. The reference your page got back from window.open() stops working, so scripts waiting on the popup can no longer see it close or talk to it directly.
MDN describes same-origin-allow-popups as a relaxation for exactly this: integrations where a document needs the benefits of isolation but also needs to open and retain a reference to trusted cross-origin documents, for example a cross-origin service for OAuth or payments.
The four values at a glance
| Value | What it means | Typical use |
|---|---|---|
unsafe-none | Default. Shares a group with any other document that allows it. | No isolation wanted. |
same-origin-allow-popups | Isolated, but may keep popups whose COOP is unsafe-none. | Pages that open OAuth or payment popups. |
same-origin | Only groups with same-origin documents that also set same-origin. | Cross-origin isolation, with no popup handles. |
noopener-allow-popups | Always opens in a new group, except from a document that also uses it. | Process-isolating same-origin apps. |
MDN also publishes the exact matrix of opener and opened values, which is worth keeping open while you test.
One catch on the popup side
The table above says a same-origin-allow-popups opener can keep a popup if the popup has COOP unsafe-none. If the identity provider sets a stricter value on its own page, the pairing changes and the link may be severed anyway. You control your page, not theirs, so test the real flow end to end.
If your page also needs cross-origin isolation for features like SharedArrayBuffer, MDN says same-origin is the value that provides it. Check whether your use case accepts the popup tradeoff before choosing.
Steps to choose
- Does any flow call
window.open()and then wait on the result? If not,same-originis the simpler choice. - If yes, name the popup's origin and confirm you trust it.
- Set
same-origin-allow-popupson your page. - Run the sign-in or payment flow in every browser you support.
- Watch for a popup that opens but never reports back to your page. That symptom usually means the groups were split.
Redirect based sign-in (full page navigation instead of a popup) sidesteps the question, because no window reference is needed.
Quick check
Is same-origin-allow-popups as strong as same-origin?
No. It still severs links to most cross-origin documents, but it deliberately permits popups whose COOP is unsafe-none. It trades some isolation for compatibility.
Does it give me cross-origin isolation?
MDN names same-origin as the value used to provide cross-origin isolation for a group. Check the current MDN page for the exact conditions before relying on any other value.
Safeguard's asset discovery and policy features help teams keep track of which first-party and third-party services their apps depend on, including identity providers, so changes to those relationships are visible. A free dependency scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
