Platform

Platform overview How it works Authorization testing Evidence & reports Private scanning Integrations

Solutions

Security agencies Product teams Regulated industries Partner programme

Learn

Blog Knowledge hub Compare

Resources

Pricing Documentation Help centre FAQ Security & data What we haven’t proved

Company

About Contact Careers Sign in to the platform Start a $199 pilot →

Home / Knowledge hub / Permissions-Policy

Knowledge hub

Permissions-Policy

A header that turns off browser features like camera or location for your pages.

Illustration explaining Permissions-Policy

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.

Cyberlop mark

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.