[{"data":1,"prerenderedAt":282},["ShallowReactive",2],{"blog-tag-en-security-headers":3},{"tagName":4,"posts":5},"Security Headers",[6,141],{"id":7,"title":8,"author":9,"body":10,"category":4,"date":107,"description":108,"extension":109,"faq":110,"meta":129,"navigation":130,"path":131,"readingTime":132,"seo":133,"slug":134,"stem":135,"tags":136,"__hash__":140},"blog\u002Fblog\u002Fen\u002Fwhat-is-cross-origin-opener-policy.md","What is the Cross-Origin-Opener-Policy Header and Why Does It Matter?","EuroraCloud Team",{"type":11,"value":12,"toc":96},"minimark",[13,17,21,26,29,32,36,39,42,46,49,52,56,59,62,66,69,72,76,79,89,93],[14,15,8],"h1",{"id":16},"what-is-the-cross-origin-opener-policy-header-and-why-does-it-matter",[18,19,20],"p",{},"The Cross-Origin-Opener-Policy header, usually written as COOP, is a response header that controls whether your page shares a browser window relationship with pages from other origins. When set to same-origin, it isolates your document into its own browsing context group, so a page from another origin that opens yours, or that you open, cannot hold a scriptable reference back to your window. This closes a class of cross-origin attacks known as XS-Leaks and side-channel attacks, and it is also the setting that unlocks certain high-performance browser features.",[22,23,25],"h2",{"id":24},"why-does-the-cross-origin-opener-policy-header-exist","Why does the Cross-Origin-Opener-Policy header exist?",[18,27,28],{},"COOP exists because opening a window creates a link that can be abused. When one page opens another with window.open(), or a page opens yours, the browser can keep a reference between the two windows through the window.opener property. If those two pages come from different origins, that reference becomes a route for a cross-origin page to probe yours.",[18,30,31],{},"The attacks this enables are subtle. They do not steal your data directly; they infer it through side channels, timing, and shared browser state, in a family of techniques the security community calls XS-Leaks. According to Mozilla's documentation, COOP was introduced specifically so a site can ensure its top-level document does not share a browsing context group with cross-origin documents, which is what severs that reference and shuts the route.",[22,33,35],{"id":34},"what-does-the-cross-origin-opener-policy-header-actually-do","What does the Cross-Origin-Opener-Policy header actually do?",[18,37,38],{},"COOP decides whether your document and the pages it interacts with belong to the same browsing context group, which is the internal browser concept that determines whether two windows can script each other. When you set it strictly, your window goes into its own group, and any cross-origin window loses its reference to yours.",[18,40,41],{},"The header has a small set of values. The default, unsafe-none, applies no isolation and lets your document share a browsing context group with cross-origin pages. The strict value, same-origin, isolates your document so only same-origin pages that also set same-origin can stay in the same group. A middle value, same-origin-allow-popups, keeps that isolation but still lets popups you deliberately open function normally, which is the practical choice for sites that rely on popup flows such as payment or single sign-on. When a cross-origin window is opened under same-origin, its window.opener becomes null, so the reference simply does not exist.",[22,43,45],{"id":44},"what-happens-if-you-do-not-set-it","What happens if you do not set it?",[18,47,48],{},"Without COOP the default is unsafe-none, which means no isolation and the window reference stays open. A cross-origin page that opens yours, or that you open, can retain a handle to your window and use it as a foothold for the side-channel techniques described above.",[18,50,51],{},"This is a quiet gap rather than a loud one. Nothing on your site looks broken, and most visitors will never trigger it, which is exactly why it tends to go unaddressed. But for a site that handles anything sensitive, a login, a patient portal, a payment step, leaving the browsing context open is an avoidable exposure, and it is one that security scanners and audits increasingly flag as a missing header.",[22,53,55],{"id":54},"how-do-you-implement-the-cross-origin-opener-policy-header","How do you implement the Cross-Origin-Opener-Policy header?",[18,57,58],{},"You set COOP as a single HTTP response header. For most sites the right starting value is Cross-Origin-Opener-Policy: same-origin-allow-popups, which gives you isolation while preserving popup-based flows; a site with no such dependencies can move to the stricter same-origin. It can be added at the web server, the application layer, or at the edge in a CDN or security layer that sits in front of the site.",[18,60,61],{},"The one strong recommendation is to test before you enforce. COOP supports a report-only mode, sent as Cross-Origin-Opener-Policy-Report-Only, which uses the browser Reporting API to tell you what the policy would break without actually breaking it. Running report-only first, watching for any popup or window flows that would be affected, and only then switching to the enforced header is the safe path, especially on a site with third-party integrations you did not build yourself.",[22,63,65],{"id":64},"what-changes-on-your-site-once-it-is-enabled","What changes on your site once it is enabled?",[18,67,68],{},"For most sites, nothing visible. Ordinary page loads, navigation, and same-origin behaviour are unaffected, and the isolation happens invisibly at the browser level. The change you gain is that cross-origin windows can no longer hold a reference to yours, which removes the attack surface without touching the user experience.",[18,70,71],{},"The place to check is any flow that deliberately opens or is opened by another origin. A payment provider, an identity provider, or an embedded tool that communicates through window references can be affected by a strict same-origin value, which is exactly why same-origin-allow-popups exists and why report-only testing matters. There is also an upside worth knowing: setting same-origin, together with the related Cross-Origin-Embedder-Policy header, puts your document into a cross-origin isolated state that some high-performance browser features require, such as SharedArrayBuffer and high-resolution timers.",[22,73,75],{"id":74},"what-should-you-do-next","What should you do next?",[18,77,78],{},"Start by checking whether your site sends a Cross-Origin-Opener-Policy header at all, since the default of no header means no isolation. If it is absent, the low-risk path is to add it in report-only mode, confirm nothing in your popup or third-party flows breaks, and then enforce same-origin-allow-popups as a sensible default or same-origin if your site has no popup dependencies.",[18,80,81,82],{},"If you would like this checked and configured correctly across your site rather than piecemeal, EuroraCloud can review your current security headers and show you what our platform resolves. ",[83,84,88],"a",{"href":85,"rel":86},"https:\u002F\u002Fwww.euroracloud.eu\u002F?utm_source=blog&utm_medium=article&utm_campaign=coop",[87],"nofollow","See what EuroraCloud resolves",[22,90,92],{"id":91},"conclusion-what-should-you-take-away-about-the-cross-origin-opener-policy-header","Conclusion: what should you take away about the Cross-Origin-Opener-Policy header?",[18,94,95],{},"COOP is a quiet but worthwhile header: it isolates your browser window from cross-origin pages, closing a class of side-channel and popup-based attacks that leave no visible sign until a scanner or an attacker finds them. For most sites the safe route is to test in report-only mode, then enforce same-origin-allow-popups, which protects the window while preserving legitimate popup flows. The single most useful step is to check whether your site sends the header today, because until it does, the default is no isolation at all.",{"title":97,"searchDepth":98,"depth":98,"links":99},"",2,[100,101,102,103,104,105,106],{"id":24,"depth":98,"text":25},{"id":34,"depth":98,"text":35},{"id":44,"depth":98,"text":45},{"id":54,"depth":98,"text":55},{"id":64,"depth":98,"text":65},{"id":74,"depth":98,"text":75},{"id":91,"depth":98,"text":92},"2026-07-13","The Cross-Origin-Opener-Policy header lets a page isolate its browser window from cross-origin pages that open it or are opened by it, closing a class of side-channel and popup-based attacks. Here is what it does, how to set it, and what changes when you do.","md",[111,113,115,118,120,123,126],{"question":25,"answer":112},"COOP exists because opening a window creates a scriptable link that can be abused. When one page opens another, the browser can keep a reference between the two windows through window.opener, and if the pages come from different origins that reference becomes a route for a cross-origin page to probe yours through side channels and timing, a family of techniques known as XS-Leaks. COOP lets a site ensure its top-level document does not share a browsing context group with cross-origin documents, which severs that reference.",{"question":35,"answer":114},"COOP decides whether your document and the pages it interacts with belong to the same browsing context group, the internal browser concept that determines whether two windows can script each other. Set strictly, your window goes into its own group and cross-origin windows lose their reference to yours. Values are unsafe-none (the default, no isolation), same-origin (strict isolation), and same-origin-allow-popups (isolation that still allows popups you open). Under same-origin, a cross-origin window's window.opener becomes null.",{"question":116,"answer":117},"What happens if you do not set the Cross-Origin-Opener-Policy header?","Without COOP the default is unsafe-none, meaning no isolation and the window reference stays open. A cross-origin page that opens yours, or that you open, can retain a handle to your window and use it as a foothold for side-channel attacks. Nothing looks broken, which is why it goes unaddressed, but for a site handling a login, patient portal, or payment step it is an avoidable exposure that scanners increasingly flag.",{"question":55,"answer":119},"Set COOP as a single HTTP response header, at the web server, the application layer, or at the edge. For most sites the right starting value is same-origin-allow-popups, which gives isolation while preserving popup flows; a site with no popup dependencies can use the stricter same-origin. Test before enforcing by using the report-only mode, sent as Cross-Origin-Opener-Policy-Report-Only, which reports what the policy would break without breaking it.",{"question":121,"answer":122},"What changes on your site once the Cross-Origin-Opener-Policy header is enabled?","For most sites nothing visible changes; ordinary page loads and same-origin behaviour are unaffected and the isolation happens at the browser level. The place to check is any flow that deliberately opens or is opened by another origin, such as a payment or identity provider, which is why same-origin-allow-popups exists and why report-only testing matters. Setting same-origin together with Cross-Origin-Embedder-Policy also enables a cross-origin isolated state required by some high-performance features like SharedArrayBuffer.",{"question":124,"answer":125},"What should you do next about the Cross-Origin-Opener-Policy header?","Check whether your site sends a Cross-Origin-Opener-Policy header at all, since no header means no isolation. If it is absent, add it in report-only mode, confirm nothing in your popup or third-party flows breaks, and then enforce same-origin-allow-popups as a sensible default, or same-origin if your site has no popup dependencies.",{"question":127,"answer":128},"What should you take away about the Cross-Origin-Opener-Policy header?","COOP is a quiet but worthwhile header that isolates your browser window from cross-origin pages, closing a class of side-channel and popup-based attacks that leave no visible sign. For most sites the safe route is to test in report-only mode, then enforce same-origin-allow-popups, which protects the window while preserving legitimate popup flows. The most useful step is to check whether your site sends the header today, because until it does, the default is no isolation at all.",{},true,"\u002Fblog\u002Fen\u002Fwhat-is-cross-origin-opener-policy","7 minutes",{"title":8,"description":108},"what-is-cross-origin-opener-policy","blog\u002Fen\u002Fwhat-is-cross-origin-opener-policy",[137,4,138,139],"Cross-Origin-Opener-Policy","Web Security","Browser Isolation","Lmp_UM5mDGWoklyUBXXHllY_CBaPGi0GFtpQ5c5p_Ds",{"id":142,"title":143,"author":9,"body":144,"category":4,"date":107,"description":253,"extension":109,"faq":254,"meta":273,"navigation":130,"path":274,"readingTime":132,"seo":275,"slug":276,"stem":277,"tags":278,"__hash__":281},"blog\u002Fblog\u002Fen\u002Fwhat-is-permissions-policy.md","What is the Permissions-Policy Header and Why Does It Matter?",{"type":11,"value":145,"toc":243},[146,149,152,156,159,162,166,179,185,189,192,195,197,200,203,207,210,213,216,218,221,224,226,229,236,240],[14,147,143],{"id":148},"what-is-the-permissions-policy-header-and-why-does-it-matter",[18,150,151],{},"The Permissions-Policy header is a response header that lets a website control which browser features its own pages, and any content embedded in them, are allowed to use. Features like the camera, microphone, geolocation, and payment can each be allowed, restricted to your own origin, or switched off entirely. Setting it means that even if a script or an embedded third party tries to reach one of those features, the browser refuses unless your policy permits it, which reduces both your privacy exposure and your attack surface.",[22,153,155],{"id":154},"why-does-the-permissions-policy-header-exist","Why does the Permissions-Policy header exist?",[18,157,158],{},"Modern browsers expose a lot of powerful capabilities to web pages: location, camera, microphone, motion sensors, and more. Any script running on your page, including third-party scripts you embedded for analytics, chat, or advertising, can in principle ask the browser to use those capabilities. Permissions-Policy exists so you can state, at the level of the whole site, which of those features are allowed and for whom.",[18,160,161],{},"The point is to close the gap between what a browser can do and what your site actually needs. Most websites never use the accelerometer or the payment API, yet without a policy those features remain reachable by any code on the page. According to MDN's documentation, when a policy blocks a feature the user is not even asked for permission, and a script's attempt to use it simply fails, which is exactly the containment you want for features you never intended to use.",[22,163,165],{"id":164},"what-does-the-permissions-policy-header-actually-do","What does the Permissions-Policy header actually do?",[18,167,168,169,173,174,178],{},"The header works as a list of directives, one per feature, each with an allowlist saying which origins may use it. The syntax is the feature name, an equals sign, and the allowed origins in parentheses, with multiple directives separated by commas, for example geolocation=(), camera=(self). An empty allowlist, written as (), disables the feature everywhere; self allows it only on your own origin; a specific origin such as (\"",[83,170,171],{"href":171,"rel":172},"https:\u002F\u002Fexample.com",[87],"\") permits that origin; and ",[175,176,177],"code",{},"*"," allows it everywhere including embedded frames.",[18,180,181,182,184],{},"A useful detail is that each feature has a default allowlist that applies when you say nothing, and depending on the feature that default is one of ",[175,183,177],{},", self, or none. So the value of setting the header explicitly is that you stop relying on per-feature defaults and instead make a deliberate, uniform decision: switch off everything you do not use, and scope everything you do use to your own origin or the specific partners that need it.",[22,186,188],{"id":187},"how-does-the-header-behave-with-embedded-iframes","How does the header behave with embedded iframes?",[18,190,191],{},"This is the part that most often trips people up, so it is worth being precise. A feature is only available inside an embedded iframe if two conditions are both met: your top-level page must allow the feature for that frame's origin in its Permissions-Policy, and the iframe itself must not have disabled it. In other words the parent page sets the outer boundary, and nothing embedded can grant itself a feature the parent has withheld.",[18,193,194],{},"There is also a per-iframe control that works alongside the header, the allow attribute on the iframe element, for example an embedded map added with a frame whose allow attribute permits geolocation. The mental model to keep is that the header is the site-wide policy and the allow attribute is the per-embed exception within it: the frame can only receive what the header already permits, and the attribute then narrows or directs it to that specific embed. This is exactly why a third-party widget sometimes reports that a feature is blocked even though the widget's own code is correct, because the containing page never allowed that feature for the widget's origin in the first place.",[22,196,45],{"id":44},[18,198,199],{},"Without the header, each feature falls back to its own default allowlist, which for several features is more permissive than a typical site needs. In practice that means capabilities you never use remain reachable, and embedded third-party content may be able to request features you would not have granted if you had been asked.",[18,201,202],{},"This is not usually an urgent hole, which is why it goes unaddressed, but it is a real one. It matters most where you embed code you did not write: an analytics tag, a chat widget, a marketing pixel. Restricting features you do not use shrinks what any of that embedded code can attempt, and it is exactly the kind of missing header that security scanners and audits now flag on almost every site that has not set it.",[22,204,206],{"id":205},"how-do-you-implement-the-permissions-policy-header","How do you implement the Permissions-Policy header?",[18,208,209],{},"You set Permissions-Policy as a single HTTP response header. A sensible starting policy is to disable the features you know you do not use and scope the rest to your own origin, for example Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), then loosen individual directives only where a genuine need exists. It can be applied at the web server, the application layer, or at the edge in a CDN or security layer in front of the site.",[18,211,212],{},"It helps to see this against a real site rather than in the abstract. Take a clinic website that shows an embedded map so patients can find the practice, and runs an online booking tool that opens a payment step, but has no other use for browser features. A policy tailored to that site might disable everything it never touches and allow only what those two functions need: geolocation scoped to the map provider's origin, payment scoped to the booking or payment provider, and camera, microphone, and the various sensor features all switched off with an empty allowlist. The result is a page where the map and the checkout work exactly as before, while every other capability is simply unavailable to any script, whether that script is yours or belongs to an embedded third party. The principle generalises: list what the site genuinely uses, allow those to the specific origins that provide them, and close the rest.",[18,214,215],{},"Test before you lock it down. The header has a report-only companion, Permissions-Policy-Report-Only, which uses the browser Reporting API to tell you what a policy would block without actually enforcing it. Running that first is the safe way to discover whether any real feature, a map that needs geolocation, a booking tool that opens a payment flow, an embedded video, would be caught by your policy, so you can allow it deliberately rather than break it by surprise.",[22,217,65],{"id":64},[18,219,220],{},"For most sites, nothing visible. Ordinary pages that do not use restricted features behave exactly as before, and visitors notice nothing, because the policy only intervenes when some code tries to reach a feature you have not allowed.",[18,222,223],{},"The place to check is any feature your own site genuinely relies on, and anything your embedded third parties need. A store locator using geolocation, a video call feature using camera and microphone, or a checkout using the payment API all need their directives set to allow the right origins, which is precisely why report-only testing matters before enforcement. Get that right once and the header quietly holds the line afterwards, allowing what you intended and refusing everything else.",[22,225,75],{"id":74},[18,227,228],{},"Start by checking whether your site sends a Permissions-Policy header at all, since without one every feature simply falls back to its default. If it is absent, the low-risk path is to add it in report-only mode, list the features you actually use, confirm nothing you rely on is being blocked, and then enforce a policy that switches off everything else.",[18,230,231,232],{},"If you would like this reviewed and configured correctly across your whole site rather than piecemeal, EuroraCloud can check your current security headers and show you what our platform resolves. ",[83,233,88],{"href":234,"rel":235},"https:\u002F\u002Fwww.euroracloud.eu\u002F?utm_source=blog&utm_medium=article&utm_campaign=permissions-policy",[87],[22,237,239],{"id":238},"conclusion-what-should-you-take-away-about-the-permissions-policy-header","Conclusion: what should you take away about the Permissions-Policy header?",[18,241,242],{},"Permissions-Policy is a quiet, practical header: it lets you switch off the browser features your site never uses and scope the ones it does to just the origins that need them, so neither your own scripts nor embedded third parties can reach capabilities you never intended to expose. The safe way to adopt it is to test in report-only mode, confirm your real features still work, and then enforce a policy that disables the rest. The single most useful step is to check whether your site sends the header today, because until it does, every feature is left on its default.",{"title":97,"searchDepth":98,"depth":98,"links":244},[245,246,247,248,249,250,251,252],{"id":154,"depth":98,"text":155},{"id":164,"depth":98,"text":165},{"id":187,"depth":98,"text":188},{"id":44,"depth":98,"text":45},{"id":205,"depth":98,"text":206},{"id":64,"depth":98,"text":65},{"id":74,"depth":98,"text":75},{"id":238,"depth":98,"text":239},"The Permissions-Policy header lets a site decide which browser features, like camera, microphone, and geolocation, its own pages and embedded content are allowed to use. Here is what it does, how to set it, and what changes when you do.",[255,257,259,262,264,267,270],{"question":155,"answer":256},"Modern browsers expose powerful capabilities such as location, camera, microphone, and motion sensors, and any script on your page, including embedded third-party code, can in principle ask to use them. Permissions-Policy exists so you can state at the site level which features are allowed and for whom, closing the gap between what a browser can do and what your site actually needs. When a policy blocks a feature the user is not even asked, and a script's attempt to use it simply fails.",{"question":165,"answer":258},"The header is a list of directives, one per feature, each with an allowlist of origins that may use it. The syntax is the feature name, an equals sign, and the allowed origins in parentheses, with directives comma separated, for example geolocation=(), camera=(self). An empty allowlist () disables the feature everywhere, self allows only your own origin, a specific origin permits that origin, and * allows it everywhere. Each feature also has a default allowlist of *, self, or none that applies when you say nothing.",{"question":260,"answer":261},"What happens if you do not set the Permissions-Policy header?","Without the header, each feature falls back to its own default allowlist, which for several features is more permissive than a typical site needs. Capabilities you never use remain reachable, and embedded third-party content may be able to request features you would not have granted. It is rarely urgent, which is why it goes unaddressed, but it matters most where you embed code you did not write, such as an analytics tag, chat widget, or marketing pixel, and scanners now flag it on almost every site that has not set it.",{"question":206,"answer":263},"Set Permissions-Policy as a single HTTP response header, at the web server, the application layer, or the edge. A sensible starting policy disables features you do not use and scopes the rest to your own origin, for example geolocation=(), camera=(), microphone=(), payment=(). Test first with the report-only companion, Permissions-Policy-Report-Only, which uses the browser Reporting API to tell you what a policy would block without enforcing it, so you can allow genuine features deliberately rather than break them by surprise.",{"question":265,"answer":266},"What changes on your site once the Permissions-Policy header is enabled?","For most sites nothing visible changes, because the policy only intervenes when code tries to reach a feature you have not allowed. The place to check is any feature your own site relies on and anything your embedded third parties need, such as a store locator using geolocation, a video feature using camera and microphone, or a checkout using the payment API, all of which need their directives set to allow the right origins. That is why report-only testing matters before enforcement.",{"question":268,"answer":269},"What should you do next about the Permissions-Policy header?","Check whether your site sends a Permissions-Policy header at all, since without one every feature falls back to its default. If it is absent, add it in report-only mode, list the features you actually use, confirm nothing you rely on is blocked, and then enforce a policy that switches off everything else.",{"question":271,"answer":272},"What should you take away about the Permissions-Policy header?","Permissions-Policy lets you switch off the browser features your site never uses and scope the ones it does to just the origins that need them, so neither your own scripts nor embedded third parties can reach capabilities you never intended to expose. The safe way to adopt it is to test in report-only mode, confirm your real features still work, and then enforce a policy that disables the rest. The most useful step is to check whether your site sends the header today, because until it does, every feature is left on its default.",{},"\u002Fblog\u002Fen\u002Fwhat-is-permissions-policy",{"title":143,"description":253},"what-is-permissions-policy","blog\u002Fen\u002Fwhat-is-permissions-policy",[279,4,138,280],"Permissions-Policy","Privacy","ZiEU5nl2sYQEXvib5MFbEOkkO5rKTR5CNWigXFoPvG0",1785141128405]