Cross-Origin Policy Bundle Generator

Generate a compatible COOP, COEP, CORP and CORS set for a stated goal - cross-origin isolation, third-party embeds, a public API, a CDN - with conflicts called out before you ship them.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

What are you trying to achieve?

Cross-Origin-Opener-Policy

Cross-Origin-Embedder-Policy

Cross-Origin-Resource-Policy

CORS

Four headers that only make sense together

COOP, COEP, CORP and CORS are usually set one at a time, by different people, at different times - and the result frequently does not add up. This tool starts from what you are actually trying to do, produces a set that is internally consistent, and names the conflicts before you deploy them.

What each one governs

COOP - whether other windows keep a reference to yours. This is what prevents tabnabbing, and it is half of cross-origin isolation.
COEP - whether cross-origin resources must opt in before your page may load them. This is the other half of isolation, and it is the one that breaks things.
CORP - who may embed this response. It is a header a resource sends about itself, and it is what other people's COEP depends on.
CORS - whether script from another origin may read this response. Different question from all three above.

The conflicts this exists to catch

COEP without COOP

The most common and the most expensive. Cross-origin isolation needs both headers. Setting COEP alone imposes the entire cost - every cross-origin image, font, script and frame must opt in or it will not load - and delivers none of the benefit, because SharedArrayBuffer and high-resolution timers stay disabled without COOP: same-origin. Teams arrive at this by following a guide halfway, or by one team owning COEP and another owning COOP.

COOP: same-origin with a popup-based flow

If your page opens a provider window and then talks to it - OAuth, 3-D Secure, some chat widgets - same-origin severs the reference in both directions and the flow stops working. same-origin-allow-popups is the documented setting for this: it still blocks inbound references, which is the part that matters for tabnabbing.

Wildcard CORS with credentials

The specification forbids Access-Control-Allow-Origin: * together with Access-Control-Allow-Credentials: true, so a server wanting both has to echo the requesting origin - and echoing whatever asks removes exactly the protection the rule exists to provide. Any site a logged-in visitor opens could then read authenticated responses from your API.

The credentialed preset here writes the origin as a placeholder rather than a value, precisely so it cannot be pasted as a reflection. It also includes Vary: Origin, without which a shared cache will hand one origin's response to another.

CORP: same-origin on a public asset

If you serve fonts, images or scripts for other sites to use, cross-origin is the setting you need - and you need it explicitly, because any consuming page with COEP: require-corp will refuse your asset without it. A CDN defaulting to same-origin breaks its own customers.

Prefer credentialless to require-corp

Where isolation is genuinely needed, Cross-Origin-Embedder-Policy: credentialless gets you there with far less breakage. Rather than refusing cross-origin resources that have not opted in, it loads them without credentials. Public assets keep working; only resources that genuinely need cookies are affected. The isolation-focused preset here chooses it for that reason.

Whichever you pick, deploy Cross-Origin-Embedder-Policy-Report-Only first. The tool emits that line alongside the enforcing one.

Verifying it worked

After deploying, open the console on the page and evaluate self.crossOriginIsolated. true means the browser accepted the combination. false with both headers set almost always means one of them is missing on that particular response - these are per-response headers, and a CDN or a framework route can easily strip one.

Check the deployed result with COOP Checker, COEP Checker, CORP Checker and CORS Checker.

Frequently asked questions

Do I need any of this if I am not using SharedArrayBuffer?

You want COOP regardless - the tabnabbing and cross-window protection applies to every site. COEP is the one that is only worth its cost if you need isolation, which is why the ordinary hardening preset leaves it out entirely.

self.crossOriginIsolated is false but I set both headers.

These are per-response headers. Check the actual response for the document itself rather than the site in general - a CDN, a cache rule or a specific framework route can strip one of them. Every cross-origin subresource also has to satisfy COEP, so one embed without CORP is enough to prevent isolation.

Will same-origin-allow-popups protect me from tabnabbing?

Yes. It severs references from windows that open yours, which is the tabnabbing direction. What it keeps is your own ability to talk to popups you opened, which is why payment and sign-in flows still work. It is not sufficient for cross-origin isolation.

Is a wildcard CORS header always wrong?

No - it is correct for genuinely public data, and it is safe precisely because browsers refuse to combine it with credentials. It is wrong when the response is not public, and it is impossible when you need cookies.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system 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.