Origin Isolation Headers Scanner

How this check works

Scanaris looks at your page's main response for two headers: Cross-Origin-Opener-Policy (COOP) and Cross-Origin-Resource-Policy (CORP). If one or both are missing, it opens a single low-severity finding naming which. It does not evaluate the value, only the presence. These are the two origin-isolation headers that are easiest to adopt; the third in the family, Cross-Origin-Embedder-Policy, is not required because it breaks any third-party resource that does not cooperate and rarely pays off on a normal site.

What each one protects

COOP decides whether your window shares a "browsing context group" with the one that opened it or with the ones you open. With same-origin, a page on another domain that opens yours with window.open no longer holds a usable reference to it (and vice versa), which cuts off cross-tab manipulation attacks and closes the route through which Spectre-style memory leaks are exploited. CORP decides who can embed your resources. With same-origin, another site cannot load your images, scripts or fonts with an <img> or <script> tag even if the URLs are public: the browser blocks the response before it reaches that site. Neither fixes an existing flaw; they are defence in depth, which is why their absence is low severity.

How to add them

Recommended values for a site that does not share resources with other domains:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin

• Nuxt: in routeRules of nuxt.config, under the '/**' rule, alongside your other headers.
• Next.js: in the headers() function of next.config.js.
• Vercel: in vercel.json, headers section. Netlify: in _headers, under /*.
• nginx: two add_header ... always; lines in the server block. Apache: Header always set in the VirtualHost.
• Express: helmet() adds them by default in recent versions; check which version you have installed.

Two things to check before enabling them

• Popup logins. If you use "Sign in with Google" or another provider in popup mode, the popup needs to talk to the window that opened it. With same-origin it stops working; use same-origin-allow-popups, which keeps the protection and allows that case.
• Resources you serve to other domains. If your images or fonts are loaded from another site of yours (a blog on a different domain, a widget that third parties embed), same-origin will block them there. Use same-site if the other site is a subdomain, or cross-origin on the specific routes of those resources.

Check it is fixed

curl -sI https://yourdomain.com | grep -iE "^cross-origin-(opener|resource)-policy:"

Both lines should appear. Then open your site, test the login and any popup integration, and look at the browser console: a resource blocked by CORP shows up there with an explicit message.

Frequently asked questions

Does this replace CORS?

No, they are complementary and point in opposite directions. CORS opens your responses to specific origins when needed; CORP closes them by default to anyone who wants to embed them. You can have CORP same-origin site-wide and open CORS on one API route.

Do I also need Cross-Origin-Embedder-Policy?

Only if you want SharedArrayBuffer or high-resolution timers (video editing, emulators, some WebAssembly apps). COEP requires everything you embed to carry CORP or CORS, and most third-party scripts do not. For an ordinary site, COOP and CORP are enough.

How much does it improve the score?

Not much in points, because it is a low-severity finding; but it is one of the few improvements with no side effects if you do the two checks above. The headers that do carry weight are in security headers and explained in HTTP headers for humans.