Defaults.Exposed › Fixes › Cross-origin isolation headers (COOP / CORP / COEP)
How to fix Cross-origin isolation headers (COOP / CORP / COEP)
Three optional browser instructions that control how other websites are allowed to interact with yours — opening it in popups, embedding its images and scripts, or pulling its resources into their own pages. They are modern hardening, not a basic must-have, and on our scoring they are informational: missing them does not lower your grade. But the two safe ones close a quiet phishing and bandwidth-theft gap, and a careful buyer's IT team will notice when they are present.
Bottom line for your business: Two of these three headers shut down sophisticated popup-phishing and stop other sites from hotlinking your images and scripts (which costs you bandwidth and can leak data). They are free, take a developer about 15 minutes, and won't break anything. The third is advanced and can break analytics, fonts and embeds — most businesses should leave it off. None of them affect your grade, so treat them as polish, not panic: do the two safe ones, skip the risky one unless you specifically need it.
What this can cost you
- A scammer opens your real site in a popup window and keeps remote control of it — silently redirecting your customer to a fake login the moment they look away. The safe header (COOP) cuts that control link entirely.
- Other websites embed your product photos, logos and scripts directly from your server (hotlinking) — you pay for the bandwidth every time their visitors load the page, and your assets show up on sites you'd never approve of.
- A prospect's security team runs a header scan before signing and sees you've added modern cross-origin hardening — small signal, but it lands you in the 'they take this seriously' column instead of the 'bare minimum' one.
- A developer, trying to be thorough, switches on the advanced isolation header (COEP) without testing — and breaks your Google Analytics, web fonts and embedded booking widget overnight. Knowing which header is safe and which is risky avoids a self-inflicted outage.
- An auditor's checklist mentions cross-origin isolation; you'd rather show 'present and correct' on the two safe ones than explain why nothing's there at all.
Why it matters. These are forward-looking browser-hardening headers. On our methodology all three are informational — they are registered with zero points and never move your grade — because they're advanced controls that a site can legitimately operate without, and one of them can do harm if misapplied. We report on them so you can see where you stand. The two safe ones (COOP and CORP) are genuinely worth adding: free, fast, and they close real popup-phishing and resource-theft gaps without breaking anything.
What these are, in plain words
When someone visits your website, their browser doesn’t just load your pages in isolation — it also decides how other websites are allowed to interact with yours. Can another site open your site in a popup and keep hold of it? Can another site reach across and embed your images and scripts in their own pages? Can your own site safely use certain powerful, locked-down browser features?
These three headers are short, invisible instructions your website sends to every visitor’s browser to answer exactly those questions. They’re known by their initials:
- COOP — Cross-Origin-Opener-Policy. Controls whether other sites that open yours in a popup window can keep remote control of it.
- CORP — Cross-Origin-Resource-Policy. Controls whether other sites are allowed to embed your images, scripts and other files in their own pages.
- COEP — Cross-Origin-Embedder-Policy. An advanced control that, combined with COOP, “isolates” your page so it can use certain powerful browser features safely.
Two of them (COOP and CORP) are safe to add and genuinely useful. The third (COEP) is advanced and can break things if switched on carelessly.
The most important thing to know up front: on our scoring, all three are informational. They do not affect your grade. A missing one costs you nothing. We report on them so you can see where you stand and tidy up the easy wins — not so you panic about a number.
What this can cost you
These are niche risks, not headline ones — but they’re real, and the fixes are free.
-
Popup phishing that keeps remote control of your real site. Without COOP, a scammer’s page can open your actual website in a popup window and hold a live reference to it. While your customer’s attention is on the scammer’s page, the attacker can redirect that popup — your real domain in the address bar — to a fake login or payment screen at the exact moment the customer turns back to it. COOP set to “same-origin” severs that control link so the popup can’t be puppeteered.
-
Other sites stealing your bandwidth (and putting your assets where you don’t want them). Without CORP, any website on the internet can embed your product photos, logos, scripts and other files straight from your server — “hotlinking.” Every visitor to their page downloads the file from you, on your bandwidth bill, with your asset appearing in a context you never approved. CORP set to “same-origin” stops outside sites embedding your resources.
-
A quiet data-leak path for advanced browser attacks. The same cross-origin embedding that enables hotlinking is also one of the paths that sophisticated, side-channel browser attacks (the Spectre family) use to read data they shouldn’t. COOP and CORP together shut that path at the browser level. For most small businesses this is belt-and-braces, but it’s free belt-and-braces.
-
A self-inflicted outage from the wrong header. The advanced one, COEP, demands that every resource your site loads explicitly opts in. Switch it on without testing and your analytics, web fonts, embedded maps, booking widgets and third-party scripts can all stop loading — because none of them were asked to opt in. This is the one way these headers can actually hurt you, and it’s entirely avoidable: don’t enable COEP without testing.
-
A missed easy signal to careful buyers. When a prospect’s IT team scans your headers before signing, finding modern cross-origin hardening in place is a small but real “these people take security seriously” signal. It won’t win a deal on its own — but it’s free to have on the right side of that ledger.
What each one actually is
COOP — Cross-Origin-Opener-Policy (safe, recommended)
When another website opens yours using a popup or window.open, the two windows can normally keep a reference to each other. That link can be abused: the opener can manipulate or redirect your window, read fragments of its URL, and stage convincing phishing using your real domain. COOP: same-origin breaks that relationship — your window becomes isolated from anything that opened it across origins. Normal browsing, your own internal links, and ordinary navigation are completely unaffected.
What “good” looks like: Cross-Origin-Opener-Policy: same-origin.
CORP — Cross-Origin-Resource-Policy (safe, recommended)
By default, your images, scripts and other files can be embedded by any site anywhere. CORP: same-origin tells browsers to refuse cross-origin embedding of your resources — so other sites can’t hotlink your assets or pull them into their pages. Your own site still loads its own resources exactly as before; only outside sites are blocked.
What “good” looks like: Cross-Origin-Resource-Policy: same-origin. (If you intentionally publish assets for others to embed — a public logo, an open API — your developer can relax this on those specific responses.)
COEP — Cross-Origin-Embedder-Policy (advanced, usually leave off)
COEP completes “cross-origin isolation”: combined with COOP, it requires that every resource your page loads explicitly opts in (via CORS or CORP). Done right, this unlocks certain powerful browser features (like SharedArrayBuffer) and adds another layer against Spectre-class attacks. But because it demands opt-in from everything you load, it readily breaks third-party tools — analytics, fonts, embedded widgets — that weren’t built to opt in. Most websites don’t need the features it unlocks and shouldn’t carry the breakage risk.
What “good” looks like: for the rare site that needs it, Cross-Origin-Embedder-Policy: credentialless — the safer value, less likely to break external resources than require-corp. For everyone else, absent is fine, and our report won’t penalise you for it.
How to fix it (free, ~15 minutes)
Hand this to your IT person or web developer — the fix is free. Adding COOP and CORP is a couple of one-line settings on your server or CDN; there’s no licence and no ongoing cost. The only instruction for the owner is: do the two safe ones, and do not enable COEP without testing.
These are response headers, set wherever your site’s responses are produced — most easily at your CDN (e.g. Cloudflare) if you have one, otherwise in your web server config.
The two safe headers (recommended for everyone)
Cloudflare — Rules → Transform Rules → Modify Response Headers → Set:
Cross-Origin-Opener-Policy=same-originCross-Origin-Resource-Policy=same-origin
Nginx:
add_header Cross-Origin-Opener-Policy "same-origin" always;
add_header Cross-Origin-Resource-Policy "same-origin" always;
Apache:
Header always set Cross-Origin-Opener-Policy "same-origin"
Header always set Cross-Origin-Resource-Policy "same-origin"
These are safe to add and will not break normal functionality. After deploying, reload a few pages and confirm the site behaves exactly as before (it should).
The advanced header (only if you specifically need it)
Do not switch this on without testing in staging first. COEP can break analytics, fonts and embedded widgets.
Cloudflare: Transform Rules → Set Cross-Origin-Embedder-Policy = credentialless.
Nginx:
add_header Cross-Origin-Embedder-Policy "credentialless" always;
Use credentialless rather than require-corp — it’s less likely to break external resources. Test thoroughly in staging; watch for any third-party script, font or embed that stops loading. If something breaks and you don’t actually need the features COEP unlocks, simply remove the header — there’s no penalty for not having it.
Platform notes
- Google Workspace / Microsoft 365: these power your email, not your website, so there’s nothing to set here. These headers belong to whatever hosts your website (your CDN, host, or server).
- Common managed hosts / site builders (Wix, Squarespace, Shopify, etc.): custom response headers may not be configurable on lower plans. If you can’t add them, that’s fine — these are informational and don’t affect your grade. Putting your site behind a CDN like Cloudflare is the usual way to gain header control.
- WordPress on your own hosting: set them in your web server config (Nginx/Apache above) or via your CDN, not in a plugin where possible — server/CDN level is cleaner and applies to every response.
Common mistakes
- Enabling COEP “to be thorough” and breaking the site. This is the big one. COEP demands opt-in from everything you load; flip it on without testing and your analytics, fonts and embeds can vanish. If you don’t need the browser features it unlocks, don’t set it.
- Treating these as urgent because a scanner mentioned them. They’re informational. The scored web headers (HTTPS, HSTS, CSP, clickjacking, MIME-sniffing) come first — fix those before spending any energy here.
- Setting CORP too strictly when you actually publish embeddable assets. If you deliberately serve a logo, badge or API for other sites to use, a blanket
same-originCORP will block them. Relax it on just those responses rather than abandoning the header everywhere. - Adding the header at the page/app level and missing some responses. Set them at the server or CDN level so they apply to every response (images, scripts, API endpoints), not just HTML pages.
- Confusing these with the SSL padlock. HTTPS encrypts the connection; these control cross-site interaction. They’re unrelated, and you want both.
A note on grade
To be completely plain: none of these three checks affect your grade. They are registered in our methodology as informational, with zero points, and a missing one never costs you anything. We surface them because the two safe ones are cheap, genuine improvements and because seeing the full picture is useful — not because there’s a number to defend. If you do nothing here, your grade is exactly the same. If you add COOP and CORP, you’ve closed a couple of real (if niche) gaps for free. That’s the right way to think about this page: optional polish, with one clearly-labelled trap to avoid.
FAQ
These don't affect my grade — should I bother at all?
Two of them, yes; one, probably not. COOP and CORP are free, take minutes, and won't break your site — they close real (if niche) attack paths, so they're worth doing as cheap hygiene. COEP is advanced and can break third-party tools, so most businesses should leave it off unless they specifically need the browser features it unlocks. None of the three change your score either way, so there's no urgency — treat the two safe ones as a tidy-up next time your developer is in the site.
I'm not technical — is this something I have to action?
Not personally, and not urgently. Because these are informational, nothing bad happens to your grade if you skip them. If you'd like to add the two safe ones, hand the 'How to fix it' section to whoever manages your website or CDN — it's a couple of one-line settings and the fix is free. The only one to flag explicitly is COEP: tell them not to switch it on without testing, because it can break analytics and embedded widgets.
What's the difference between these and the headers that DO affect my grade?
The scored web-security headers — HTTPS redirect, HSTS, Content-Security-Policy, clickjacking protection (X-Frame-Options), and MIME-sniffing protection — defend against common, widely-exploited attacks, so missing them costs points. The three on this page (COOP, CORP, COEP) are newer, more specialised browser-isolation controls. They're good practice but not yet baseline expectation, so we report them without scoring them. Do the scored ones first; these are polish on top.
Will adding COOP or CORP break my website or my partners' integrations?
The recommended settings (both 'same-origin') are designed to be safe. COOP only severs the link to windows your site opens in pop-ups — normal browsing, your own pages, and ordinary links are unaffected. CORP only stops *other* sites from embedding your images and scripts; your own site loads its own resources exactly as before. If you actually serve assets (like a public logo or an API) that other sites are meant to embed, your developer can use a more permissive setting on those specific responses. The one that genuinely risks breakage is COEP — keep that one off unless tested.
What does 'hotlinking' cost me, really?
When another site embeds your image or script straight from your server instead of hosting their own copy, every visitor to their page downloads it from you — on your bandwidth bill, and showing your asset in a context you didn't approve. For a small business it's rarely catastrophic, but it's free money out the door, and CORP ('same-origin') stops it at the browser level. It also closes a subtle data-leak path that advanced (Spectre-class) browser attacks rely on.
What does 'good' look like for each of these?
COOP: a Cross-Origin-Opener-Policy header set to 'same-origin'. CORP: a Cross-Origin-Resource-Policy header set to 'same-origin'. COEP: a Cross-Origin-Embedder-Policy header — and if you set it at all, 'credentialless' is the safer value than 'require-corp'. Our report simply notes whether each is present and what it's set to; it never penalises you for a missing one. Aim for COOP and CORP present; leave COEP absent unless you've tested it.