# Does your site keep windows from other sites away from it?

By Mark Kashef, founder of Lockpick. Published 2026-10-08, updated 2026-10-08.

The window isolation check credits a Cross-Origin-Opener-Policy on your pages. Absence is never scored, because popups for sign-in and payments may need it off.

The window isolation check notes when your pages send a Cross-Origin-Opener-Policy of same-origin or same-origin-allow-popups. It keeps windows from other sites from holding a reference to yours.

## What does this check look at?

It looks at whether your pages declare a Cross-Origin-Opener-Policy that keeps windows from other sites away from them. MDN explains that this prevents a set of cross-origin attacks referred to as XS-Leaks.

Pulse and Deep scans both run it.

## What does a result mean?

| What the report shows | What it means | What to do |
| --- | --- | --- |
| Pass | A same-origin or same-origin-allow-popups policy is declared. | Nothing. |
| Not tested | No such policy was seen. It is not counted against you. | Optional. Add it after testing sign-in and payment popups. |

Absence can be deliberate for sign-in and payment popups, so it is never scored as a failure. A declared policy does not prove every page sends it, since the scan reads a sample of pages.

## How serious is a finding?

Treat this as a hardening gap. It makes an attacker’s job easier but gives them no path of its own, so fix it after anything more direct. Confidence starts low, because it is inferred from headers or declarations rather than shown directly. The report lists what to fix by how directly someone could use it, not by the severity label.

### What does a confirmed finding have to show?

| Part | For this check |
| --- | --- |
| Where it starts | Content or a frame an attacker can influence |
| The protection that should stop it | A browser protection header is missing or weak |
| What is reached | How browsers treat your pages |
| What follows | A hardening gap; no exploit was shown |

## Which standards does it relate to?

| Standard | Reference |
| --- | --- |
| OWASP Top Ten | `A02:2025` Security Misconfiguration |
| CWE | `CWE-1021` |
| ASVS | `v5.0.0-3.4.8` |

Each one is a related control, not a verification. A scan sees what anyone online can see, so it never proves a whole requirement is met.

## Fix it with your AI

Test popup flows before and after, since sign-in providers and payment pages often open in a popup.

:::fix-prompt any
Add the header Cross-Origin-Opener-Policy: same-origin-allow-popups to my site's pages. Then test every flow that opens or is opened by a popup window, such as social sign-in, payment checkout and OAuth connections. If any of them breaks, tell me which one and leave the header off for that page.
:::

## How to check

Say Atlas, our example app at `atlas.example`, signs people in with a provider popup. same-origin-allow-popups keeps that flow working while still isolating the main window.

The free [quick check](/check) covers this on your homepage with no account, and a Pulse scan from your account adds your scripts and public records. [Pulse or Deep](/docs/get-started/pulse-or-deep) explains the difference.

## Questions people ask

### Why is a missing isolation policy not a problem?

Many sites need cross-site popups for sign-in or payments, and leaving the policy off is often the right choice. The check only credits it when present.

### Is this the same as framing protection?

No. Framing protection controls who can embed your page. Window isolation controls references between separate windows.

## Sources

- [Cross-Origin-Opener-Policy header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cross-Origin-Opener-Policy), MDN Web Docs, read on 2026-10-07
- [How we rate findings](https://www.lockpick.app/docs/security/how-we-rate-findings), Lockpick docs, read on 2026-10-07