COOP and COEP Header Generator

After the Spectre processor flaws were disclosed in 2018, browsers restricted the features that make timing attacks practical. Shared memory between threads and high-resolution timers, which WebAssembly with threads, in-browser video tools and some games need, are available only to pages that are cross-origin isolated. Isolation places a page in its own process group, away from other sites’ windows and data. Getting there takes two response headers, plus cooperation from every resource the page embeds, and this page helps you set and understand them.

The three headers

Cross-Origin-Opener-Policy (COOP) controls the relationship with windows opened across origins. With same-origin, a cross-origin page can no longer hold a reference to your window, and window.opener is null. same-origin-allow-popups keeps popups you open working but does not isolate the page. Cross-Origin-Embedder-Policy (COEP) controls what your page may embed: with require-corp every cross-origin subresource must opt in. Cross-Origin-Resource-Policy (CORP) is the opt-in a resource sends, with values same-origin, same-site and cross-origin.

A worked example

Press “Sample: full cross-origin isolation”. The page sets Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp, and lists three notes. Medium: COOP same-origin cuts the link to cross-origin popups, so sign-in flows using OAuth popups and payment windows may break. Medium: COEP require-corp blocks resources that do not opt in, because every cross-origin image, script, font or iframe must send Cross-Origin-Resource-Policy: cross-origin or be loaded with CORS, so third-party widgets without those headers stop loading. Good: the page becomes cross-origin isolated, self.crossOriginIsolated is true, and SharedArrayBuffer, precise timers and memory measurement become available.

The cost of isolation

Everything on the page must cooperate. Images from a CDN need CORP or CORS headers, third-party iframes such as maps and videos must be isolated-friendly, and analytics scripts may fail. Popup-based login breaks under COOP same-origin, so use redirect flows or same-origin-allow-popups on the page that opens popups. List your embeds before you start, and ask vendors which headers they send.

Credentialless

COEP credentialless is a gentler mode: cross-origin no-CORS requests are sent without cookies, so most public resources load without opting in. It reaches the same isolation. It is newer and not supported by every browser, so test in the ones your users have.

Deploying safely

Use the Report-Only variants first: Cross-Origin-Embedder-Policy-Report-Only and its COOP counterpart log what would be blocked without blocking it. Collect the reports, fix or replace the offending resources, then switch to enforcing headers. The headers must be on the main document response, not only on the scripts.

Limits

The page cannot crawl your site to say which resources will be blocked, so you need the browser console and reports. Support differs between browsers and versions. Isolation is one layer: it does not replace a Content-Security-Policy or good input handling.

A rollout plan

Begin by listing every cross-origin resource the main page loads: fonts, images, scripts, frames and API calls. Ask each provider whether it sends Cross-Origin-Resource-Policy or allows CORS, and replace those that do not. Deploy the Report-Only headers for a week of normal traffic, read the reports and fix what they show. Then enforce COOP and COEP together on the document that needs shared memory, and test the sign-in and payment flows again, since popups are the first thing to break. Keep the old headers ready so that you can roll back quickly if a third-party widget fails.

Related tools

• Security Headers Generator and Auditor audits these headers with the rest.
• Permissions-Policy Generator limits browser features.
• CORS Header Generator and Tester sets the CORS headers that satisfy COEP.
• CSP Generator and Evaluator restricts what the page can load.