[{"data":1,"prerenderedAt":168},["ShallowReactive",2],{"blog-tag-en-permissions-policy":3},{"tagName":4,"posts":5},"Permissions-Policy",[6],{"id":7,"title":8,"author":9,"body":10,"category":134,"date":135,"description":136,"extension":137,"faq":138,"meta":157,"navigation":158,"path":159,"readingTime":160,"seo":161,"slug":162,"stem":163,"tags":164,"__hash__":167},"blog\u002Fblog\u002Fen\u002Fwhat-is-permissions-policy.md","What is the Permissions-Policy Header and Why Does It Matter?","EuroraCloud Team",{"type":11,"value":12,"toc":122},"minimark",[13,17,21,26,29,32,36,51,57,61,64,67,71,74,77,81,84,87,90,94,97,100,104,107,115,119],[14,15,8],"h1",{"id":16},"what-is-the-permissions-policy-header-and-why-does-it-matter",[18,19,20],"p",{},"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,23,25],"h2",{"id":24},"why-does-the-permissions-policy-header-exist","Why does the Permissions-Policy header exist?",[18,27,28],{},"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,30,31],{},"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,33,35],{"id":34},"what-does-the-permissions-policy-header-actually-do","What does the Permissions-Policy header actually do?",[18,37,38,39,45,46,50],{},"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 (\"",[40,41,42],"a",{"href":42,"rel":43},"https:\u002F\u002Fexample.com",[44],"nofollow","\") permits that origin; and ",[47,48,49],"code",{},"*"," allows it everywhere including embedded frames.",[18,52,53,54,56],{},"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 ",[47,55,49],{},", 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,58,60],{"id":59},"how-does-the-header-behave-with-embedded-iframes","How does the header behave with embedded iframes?",[18,62,63],{},"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,65,66],{},"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,68,70],{"id":69},"what-happens-if-you-do-not-set-it","What happens if you do not set it?",[18,72,73],{},"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,75,76],{},"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,78,80],{"id":79},"how-do-you-implement-the-permissions-policy-header","How do you implement the Permissions-Policy header?",[18,82,83],{},"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,85,86],{},"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,88,89],{},"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,91,93],{"id":92},"what-changes-on-your-site-once-it-is-enabled","What changes on your site once it is enabled?",[18,95,96],{},"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,98,99],{},"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,101,103],{"id":102},"what-should-you-do-next","What should you do next?",[18,105,106],{},"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,108,109,110],{},"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. ",[40,111,114],{"href":112,"rel":113},"https:\u002F\u002Fwww.euroracloud.eu\u002F?utm_source=blog&utm_medium=article&utm_campaign=permissions-policy",[44],"See what EuroraCloud resolves",[22,116,118],{"id":117},"conclusion-what-should-you-take-away-about-the-permissions-policy-header","Conclusion: what should you take away about the Permissions-Policy header?",[18,120,121],{},"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":123,"searchDepth":124,"depth":124,"links":125},"",2,[126,127,128,129,130,131,132,133],{"id":24,"depth":124,"text":25},{"id":34,"depth":124,"text":35},{"id":59,"depth":124,"text":60},{"id":69,"depth":124,"text":70},{"id":79,"depth":124,"text":80},{"id":92,"depth":124,"text":93},{"id":102,"depth":124,"text":103},{"id":117,"depth":124,"text":118},"Security Headers","2026-07-13","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.","md",[139,141,143,146,148,151,154],{"question":25,"answer":140},"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":35,"answer":142},"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":144,"answer":145},"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":80,"answer":147},"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":149,"answer":150},"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":152,"answer":153},"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":155,"answer":156},"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.",{},true,"\u002Fblog\u002Fen\u002Fwhat-is-permissions-policy","7 minutes",{"title":8,"description":136},"what-is-permissions-policy","blog\u002Fen\u002Fwhat-is-permissions-policy",[4,134,165,166],"Web Security","Privacy","ZiEU5nl2sYQEXvib5MFbEOkkO5rKTR5CNWigXFoPvG0",1785141128397]