Home / Knowledge hub / Permissions-Policy
Knowledge hub
Permissions-Policy
A header that turns off browser features like camera or location for your pages.
What it means
Permissions-Policy is an HTTP response header that tells the browser which powerful features your page, and any frames inside it, may use. Examples are camera, microphone, geolocation, payment and fullscreen. Anything you do not allow is switched off.
It was previously called Feature-Policy. The syntax is a list such as camera=(), geolocation=(self), where empty parentheses mean no one may use the feature and self means only your own origin.
Why it matters
Your page often contains code you did not write: ad scripts, chat widgets, embedded videos, a compromised dependency. If a feature is not locked, that code can ask the visitor for the camera or location under your site's name, and people tend to trust your name.
Switching off what you do not use reduces what a mistake or an injected script can do. It is a small control with an unusual property: nothing to maintain once set, and a clear answer for a security reviewer.
How it shows up
You meet it in response headers from the web server, CDN or framework. It works alongside the allow attribute on iframes, where you give a specific frame a specific feature. Browser support varies by feature, and some browsers still lag.
The mistakes repeat. No header at all. A copy-pasted policy that disables features the app really uses, so a video call breaks. Granting a feature to *. Forgetting that embedded frames from other sites inherit the choice. Start with everything off and open only what you need. See security headers.
Questions people ask
Permissions-Policy, answered
Is Permissions-Policy the same as the permission prompt?
No. The prompt asks the visitor. The policy decides whether your page may even ask.
If the policy disables a feature, the browser never shows the prompt.
Which features should we turn off?
Everything the app does not use, typically camera, microphone, geolocation, payment and USB.
Keep only what a feature in your product requires, and allow it for your own origin.
Does it protect against XSS?
Not against the injection. It limits what injected or third-party code can do afterwards.
Use a content security policy and output encoding for the injection itself.
Why was Feature-Policy renamed?
The specification changed its syntax and name. Feature-Policy is deprecated and the new header is the one to send.
Some old guides still show the old form.
How do we check it?
Read the headers on your main pages and on pages that embed other sites. Use a header scanner or the browser developer tools.
Then test that the features you keep still work.
Sources
Where this comes from
Related
Terms that sit next to this one
Security headers
Response headers that switch on browser protections against common web attacks.
Referrer-Policy
A header controlling how much of your page address is sent to other sites.
Iframe sandbox
An attribute that strips embedded content of most of its powers.
Content Security Policy
A header telling the browser which scripts a page may load.
XSS
An attacker's script running in your pages, in your customers' sessions.
What may your page switch on?
Missing headers are easy to list, so we focus on proving what matters: injected or third-party code that reaches something it should not, shown with the request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.