Cross-Origin headers missing? Most UK business websites have this gap

A marketing agency in Bristol had its booking page embedded by a third-party site without permission. Visitors filled in their details on what looked like the agency's own form, except the page sat inside someone else's frame, lifting whatever was typed. The agency's website had no security headers stopping another page from embedding it that way. Nobody had set any, because nobody had been told they needed to.

Cross-Origin-Embedder-Policy and Cross-Origin-Opener-Policy are two of the more obscure security headers, and they're also two of the most commonly missing ones we see on a scan. Most business owners have never heard either term, which is exactly why they're worth explaining properly rather than skipping past.

What these two headers actually control

Cross-Origin-Opener-Policy, usually shortened to COOP, controls whether your page can be accessed or manipulated by a window opened from a different origin, like a popup or a linked tab. Without it set, another site can open your page in a new window and, in certain browser configurations, interact with it in ways that leak information between the two contexts.

Cross-Origin-Embedder-Policy, or COEP, controls whether resources from other origins, such as images, scripts, or iframes, can be loaded into your page without those resources explicitly opting in. Together, COOP and COEP create what browsers call cross-origin isolation, a boundary that stops your page's content and data from leaking sideways into a different site's context, and vice versa.

Neither header existed in the original web security model. Browsers added them specifically because attackers found ways to exploit the assumption that pages from different origins couldn't see each other's data, even when standard same-origin protections were technically in place.

Why this matters for a business that isn't running anything fancy

It's tempting to assume these headers only matter for complex web applications, not a standard business website. That's only partly true. Even a simple site with a contact form, a booking widget, or an embedded payment field benefits from cross-origin isolation, because it closes the door on a category of attack where a malicious page references yours in the background, attempting to read data the visitor assumes is private to your site alone.

If your business uses any embedded third-party widget, like a booking calendar, live chat, or payment iframe, the absence of these headers also affects how safely that embedded content can interact with the rest of your page.

Where this sits in Cyber Essentials

These two headers fall under Cyber Essentials' CE2 Secure Configuration control. They're checked automatically during a scan rather than through self-assessment, because they're either present in your server's response or they're not. There's no judgment call involved, which makes them straightforward to fix once you know they're missing.

Assessors won't necessarily walk you through every individual header by name, but the automated tooling many assessors use to support a Cyber Essentials review will surface exactly this kind of gap, the same way our own scan does.

How to add COOP and COEP to your site

Both headers are added at the web server or application level, not through DNS or a third-party service. The specific syntax depends on your stack. For COOP, the header is typically set as Cross-Origin-Opener-Policy: same-origin, which restricts window interactions to pages on your own domain. For COEP, it's usually Cross-Origin-Embedder-Policy: require-corp, which requires any embedded resource to explicitly permit cross-origin loading.

If your site runs through a content delivery network or reverse proxy, like Cloudflare or a similar service, headers can often be added at that layer without touching your application code directly, which is the simplest route for most small business sites. If you manage your own server configuration, the headers go in your Nginx or Apache config, or in middleware if you're running a framework like Express or Next.js.

Test carefully after adding COEP in particular. It's the stricter of the two, and if your site loads any third-party resource that doesn't support cross-origin permissions, that resource may stop loading until the third party adds the necessary headers on their end too.

Frequently asked questions

Will adding these headers break anything on my website? COEP can occasionally cause embedded third-party content to stop loading if that content doesn't send the right cross-origin permissions itself, so test your site after adding it before treating the change as complete.

Do I need both headers, or just one? They work together but serve different purposes, so Cyber Essentials and general good practice both expect both to be present rather than just one.

Why have I never heard of these headers if they're this important? They're newer than headers like X-Frame-Options or HSTS, and browser support has only become consistent in recent years, which is part of why awareness among small business owners is low.

Does my website platform (Squarespace, Wix, Shopify) let me add these headers myself? Most no-code website builders don't expose server header configuration directly, so you'd typically need to ask the platform's support team or use a CDN layer in front of the site if one is available.

How do I check if these headers are already set on my site? Browser developer tools will show response headers under the Network tab, or a scan will surface the same information without needing to dig through developer tools manually.

Run a free scan of your domain and your CE Readiness checklist will show exactly which security headers are missing, ranked by severity, ready before your assessor asks: olimpio.io/free-scan