Wiki · Concept · Last reviewed July 2, 2026

Cross-Origin Opener Policy

Cross-Origin Opener Policy is a browser security boundary that decides when top-level windows remain connected through the same browsing context group and opener relationship.

Category: Concept Published: June 25, 2026 Modified: July 2, 2026 Last reviewed: July 2, 2026 Tags: browser security, cross-origin isolation, popups, agents, web governance

Definition

Cross-Origin Opener Policy, or COOP, is an HTTP response-header mechanism defined in the HTML Standard. It controls whether a top-level document shares a browsing context group with another top-level document that opened it, or that it opened. MDN describes the header as a way for a website to control whether a new top-level document opened with Window.open() or by navigation is placed in the same browsing context group or in a new one.

When a document is placed in a new browsing context group, references between the document and its opener can be severed. That reduces the ability of cross-origin windows to retain handles, script reachable properties, or use opener relationships in XS-Leak-style attacks. COOP may lead to stronger process isolation in browser implementations, but the governance claim should be about the browser-defined browsing context boundary, not a guaranteed process model.

COOP is not Cross-Origin Resource Sharing. CORS decides whether scripts may read selected cross-origin responses. COOP decides whether top-level windows remain connected through the opener relationship and shared browsing-context machinery.

Snapshot

Current Context

As of July 2, 2026, COOP is part of the WHATWG HTML Living Standard and is implemented as an HTTP response header described by MDN. The HTML Standard's current opener policy values include unsafe-none, same-origin-allow-popups, same-origin, same-origin-plus-COEP, and noopener-allow-popups, with same-origin-plus-COEP reserved for the combined isolation state rather than direct header syntax.

COOP is most visible in two operational settings. First, it limits opener relationships for security-sensitive pages, reducing exposure to cross-origin attacks that depend on retained window references. Second, together with Cross-Origin Embedder Policy and a compatible Permissions Policy, it is part of the cross-origin isolation setup used for browser features such as SharedArrayBuffer, more precise timers, and memory measurement APIs.

Current guidance emphasizes staged rollout. Report-only mode can show when a stricter policy would force browsing context group switches before the site breaks production popup or navigation flows. That is especially important for pages that depend on cross-origin identity, payment, media, or embedded productivity providers.

How It Works

unsafe-none is the default. It permits sharing a browsing context group with other documents unless another document's policy requires separation. It is useful as the baseline, but it does not create opener isolation.

same-origin allows sharing only with same-origin documents that also use the same policy. This is the common strict policy used when a site wants cross-origin isolation and can tolerate stricter popup behavior.

same-origin-allow-popups is similar to same-origin, but it relaxes popup behavior for cases where a page needs cross-origin isolation benefits while retaining a reference to trusted cross-origin popups using unsafe-none. MDN names OAuth and payments as examples of this compatibility need.

noopener-allow-popups forces a new browsing context group regardless of the predecessor and severs opener relationships, while still supporting popup flows. The HTML Standard warns that it does not create a robust security boundary between same-origin documents by itself; same-origin storage, communication channels, cookies, framing, and server endpoints still need separate review.

same-origin-plus-COEP appears in the standard when Cross-Origin-Opener-Policy: same-origin is combined with an embedder policy compatible with cross-origin isolation. Developers should not write it as a COOP header value. They should set the actual COOP and COEP headers and verify the resulting crossOriginIsolated state in the target browser.

The standard also defines Cross-Origin-Opener-Policy-Report-Only and a report-to parameter, so a site can observe would-be policy effects through reporting before enforcing a stricter boundary. In practice, cross-origin isolation for powerful features such as SharedArrayBuffer also depends on compatible embedder policy and permission constraints, not COOP alone.

Agent Context

COOP matters for browser agents because many delegated workflows use popups: login, OAuth consent, payment, wallet authorization, support chat, document preview, and admin consoles. A human may notice when a popup cannot communicate with the opener. An agent may only see that a task stalled, a callback failed, or a window handle appears closed.

This is not just a usability issue. A popup boundary can be a security control that prevents one document from scripting, probing, or retaining references to another. When an agent tries to work around a blocked opener relationship by reusing cookies, copying URLs, proxying content, or retrying through a different tool, it may accidentally bypass the site operator's intended isolation model. Agent runtimes should treat COOP effects as boundary evidence, not as ordinary page flakiness.

OAuth is the clearest example. A browser-based login or consent flow may need a popup or redirect to complete. A stricter COOP setting can make the opener see the window as closed or lose the expected communication path. The agent should surface that state to the user or policy layer rather than inventing a shortcut that exposes authorization codes, tokens, payment details, or account state to the model transcript.

Governance and Safety

Governance starts by separating functional failure from policy enforcement. A failed popup callback may mean a broken integration, but it may also mean the browser created a new browsing context group because of COOP. For high-risk agent tasks, logs should capture the opener URL, opened URL, response header values, report-only header values, frame or window relationship, browser version, and whether a policy report was generated through Reporting API.

COOP can also support deployment review. A site that handles passwords, payments, privileged administration, or sensitive identity flows may choose stricter opener isolation. A site that depends on third-party popup integration may need same-origin-allow-popups or a staged report-only period. The right question is not whether isolation is always better; it is what relationship the page should have with windows around it.

For AI and automation systems, the governance record should connect COOP to the rest of the browser boundary: COEP, CORP, Content Security Policy, Permissions Policy, storage partitioning, OAuth architecture, and agent tool permissions. A COOP header is useful evidence, but it is one layer in a wider browser-security and agent-sandboxing posture.

Failure Modes

Defense Pattern

Limits

COOP does not authenticate users, authorize cross-origin reads, clear storage, prevent server-side tracking, or replace Content Security Policy. It is a top-level window and browsing-context boundary. Same-origin documents may still share other channels unless separate controls restrict them.

The HTML Standard warns developers using noopener-allow-popups not to rely on client-side features accessible to other same-origin documents, such as local storage and BroadcastChannel, or on server endpoints that expose sensitive data to non-navigation requests. In agentic browsers, the same warning applies to automation state: isolating the opener does not isolate every memory, cache, credential, connector, extension, browser profile, or server-side session.

COOP also does not prove that a site is safe to automate. A page can have a correct opener policy and still contain prompt-injection content, malicious scripts allowed by CSP, unsafe OAuth storage, weak authorization checks, or overly broad agent tools. Treat COOP as a boundary signal, not a safety certificate.

Minimum Evidence Record

For agent-mediated browsing, preserve the opener URL with secrets removed, opened URL with secrets removed, origins, exact COOP and report-only header values, related COEP and Permissions Policy values, report-to endpoint name if present, browser and version, popup creation method, observed window relationship, task identifier, user approval event, and any policy report identifier. Avoid retaining full tokens, query secrets, authorization codes, payment details, cookies, local-storage contents, or captured popup contents unless a narrowly scoped incident review requires them.

Source Discipline

Use the HTML Standard for formal policy values, the derived same-origin-plus-COEP state, report-only behavior, browsing context group switching, and warnings about same-origin client-side channels. Use MDN for implementation-oriented syntax and browser-facing explanations. Use web.dev or Chrome documentation only when discussing cross-origin isolation rollout and operational impact, not as a substitute for the header definition.

Claims about a live deployment should cite observed response headers, browser version, navigation or popup method, report-only versus enforce disposition, and the tested user flow. Do not infer cross-origin isolation from COOP alone, and do not infer successful popup security from the absence of a console error.

Spiralist Reading

Spiralism reads COOP as a boundary around attention. A window may look like a neighbor, but the browser can decide that it belongs in another group, with fewer inherited powers and fewer silent handles.

The agent-era lesson is consent by connection. Opening a window should not automatically mean keeping a relationship. Delegated systems need to respect when the browser cuts the cord, because sometimes the broken handle is the protection.

Open Questions

Sources

Return to Wiki