--- title: Permissions-Policy Explained: switching off what your site never uses description: Your page can ask for the camera, the microphone and the visitor's location — and so can every script and iframe you embed, in your name. Permissions-Policy is how you say which of those your site actually needs. canonical: https://watchfor.io/blog/permissions-policy-explained --- [All posts](/blog) [Security](/blog/category/security) Sep 08, 2026 · 4 min read · WatchFor Team # Permissions-Policy Explained: switching off what your site never uses Your page can ask for the camera, the microphone and the visitor's location — and so can every script and iframe you embed, in your name. Permissions-Policy is how you say which of those your site actually needs. Browsers can do a lot more than show pages. A website can ask to use the camera, the microphone, the visitor's exact location, the motion sensors, the clipboard, and a dozen other things. The visitor gets a prompt and decides. Here's the part that surprises people: that permission belongs to the page, not to your code. Every script you include and every iframe you embed can ask for it too, and the prompt the visitor sees says your domain. Permissions-Policy is how you decide which capabilities the page may use at all — including by the code you didn't write. ## What that looks like in practice You embed a third-party widget: a chat box, an ad, a video player, an analytics script. Each one runs on your page with your name on it. If one of them calls the geolocation API, the visitor sees: app.example.com wants to know your location They have no way to tell that the request came from an embedded advert rather than from you. If they click Allow, the answer goes to whoever asked. Nothing is broken here either. This is the platform working as designed, and the design assumes you'll say what your site needs. ## Why it's worth doing even though nothing is wrong Most sites use none of these capabilities. A blog doesn't need a microphone; a checkout doesn't need motion sensors. Leaving them all available is not causing you a problem today — it just means: - A compromised or careless third-party script can ask in your name. Prompts that look like they came from you damage trust whether or not anyone accepts. - An [XSS](/blog/content-security-policy-explained) bug gets a bigger blast radius. Injected code inherits everything the page is allowed to do. - You have no record of what your site is entitled to. Setting the policy is the moment you find out which vendor wanted the clipboard. This is why it shows up in a [website audit](/smart-website-audit) as something worth setting rather than something urgently wrong. It's a door you're closing before anyone tries it. ## The fix Deny everything you don't use, then open what you do: Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), magnetometer=(), gyroscope=(), accelerometer=(), interest-cohort=() The syntax reads like a small allow-list per feature: Written as Meaning camera=() Nobody may use the camera — not the page, not any frame camera=(self) Your own pages may, embedded third parties may not camera=(self "https://meet.example.com") Your pages, plus that one named origin camera=* Anything on the page may ask. The default, effectively So a video-call app might send camera=(self), microphone=(self), geolocation=() , and a marketing site can deny the lot. This replaced Feature-Policy . Same idea, different name and a different syntax. If you find Feature-Policy in an old config, it's the ancestor of this header — write the new one. ## What could break Less than you'd fear, but there is one real trap: a policy applies to embedded frames too, and a denied feature can't be re-granted by the frame. So walk through what your pages actually embed before shipping it: - Video or voice calls — needs camera and microphone , usually (self) . - Store locators, delivery estimates, "find nearest" — needs geolocation . - Embedded payment forms — Apple Pay and Google Pay use the payment feature; an embedded provider's iframe may need payment=(self "https://pay.provider.com") . - Maps, video embeds, hardware integrations — check each one's documentation for what it asks for. If you're unsure, start by denying only the capabilities you're certain about — camera , microphone , usb , the motion sensors — and leave the rest until you've checked. ## What it isn't - It's not a privacy guarantee. It governs browser capabilities, not what a script does with data it can already see. A [Content Security Policy](/blog/content-security-policy-explained) and a [Referrer-Policy](/blog/referrer-policy-explained) cover different halves of that. - It's not a substitute for auditing what you embed. The best version of this header is a short list because your page loads few strangers, not because you fought each one. - Support varies by feature. The common ones are broadly supported; the exotic ones less so. It's a layer, not a wall. ## Keeping it there Like the rest of them: one config line, no symptom when it vanishes. The free [HTTP header checker](/http-header-checker) shows what your site sends right now, the [Smart Website Checker](/smart-website-audit) reviews all six recommended headers together, and an [API monitor](/docs/monitors/api) can assert it stays present after every deploy. ## The bottom line In one line What A header listing which browser capabilities the page — and anything it embeds — may use. Why Third-party scripts and iframes can otherwise request camera, mic or location in your name. Danger without it A prompt branded with your domain, sent by code you didn't write. Add Permissions-Policy: camera=(), microphone=(), geolocation=() , then open what you use. Check first Calls, maps, and embedded payment frames. It's the least dramatic header on the list and one of the easiest wins: deny what you never use, and the answer to "could a script on our site ask for the microphone?" stops being "probably". Related: [Content Security Policy explained](/blog/content-security-policy-explained), [Referrer-Policy explained](/blog/referrer-policy-explained), [Clickjacking explained](/blog/clickjacking-explained). [#security](/blog/tag/security)[#web](/blog/tag/web) ## Monitor your website & APIs Continuous HTTP/HTTPS checks with status-code, latency and content assertions — plus instant alerts when something breaks. [Learn more](/http-monitoring)[Start free](/auth/sign-up) Share this article --- Canonical page: https://watchfor.io/blog/permissions-policy-explained · Site guide: https://watchfor.io/llms.txt