What is Permissions-Policy?

Permissions-Policy is a security header that lets you decide which powerful browser features your website, and any third-party content it embeds, is allowed to use. Camera, microphone, geolocation, payment prompts, fullscreen and more can each be switched on or off at the page level. It was previously called Feature-Policy, and you may still see that older name in some tools, but Permissions-Policy is the current standard.

What Permissions-Policy is for

Modern browsers expose a lot of capabilities to web pages. Most sites need only a handful of them, yet by default a page and everything it embeds can request nearly all of them. Permissions-Policy flips that around: you explicitly list which features are permitted and for whom, and the browser blocks every request for anything you did not allow. If a page never uses the microphone, denying microphone access means a malicious script or a compromised third-party widget cannot quietly turn it on.

Why Permissions-Policy improves security

The header shrinks your attack surface. Third-party scripts, embedded iframes and injected code all inherit the browser features available to the page. By denying features you do not use, you remove tools an attacker would otherwise have. It also protects your visitors’ privacy, because sensitive capabilities like location and camera cannot be abused by anything running on the page, whether that is your own code or a tag you loaded from elsewhere.

How the syntax works

Permissions-Policy is a list of features, each followed by an allowlist in parentheses. An empty allowlist, written as (), blocks the feature everywhere. The keyword self permits it on your own origin, and you can name specific trusted origins as well.

• geolocation=() disables location access for the whole page.
• camera=(), microphone=() blocks camera and microphone entirely.
• fullscreen=(self) allows fullscreen only for your own pages.
• payment=() switches off the Payment Request API if you do not use it.

A common starting header simply denies the features a typical site never needs, then selectively re-enables anything genuinely required.

Permissions-Policy versus Content Security Policy

The two headers solve different problems. A Content Security Policy governs where content may load from, while Permissions-Policy governs which device and browser features that content may use. They complement each other, and a strong baseline sets both. For background on the first, see our guide on what a Content Security Policy is.

How to set Permissions-Policy

Send it as an HTTP response header from your server so it applies site-wide. On Apache add a Header directive, on Nginx add an add_header line, and on WordPress send it through the send_headers action or a reputable security-headers plugin. Start restrictive by denying features you do not use, deploy, then test that legitimate functionality such as an embedded map or a video call still works, re-enabling only what you need.

A sensible default Permissions-Policy

If you want a practical starting point, deny the features that the vast majority of websites never use and only open up the ones you can name a reason for. Location, camera, microphone, USB access and the payment prompt can almost always be switched off on a standard marketing site, blog or brochure page, because none of that content asks the browser for those capabilities. A shop that takes card details, a support page with a click-to-call video widget, or an app that shows an interactive map are the exceptions, and even then you enable only the single feature involved and only for the origin that needs it. Working from a deny-by-default position is safer than trying to guess every feature an attacker might reach for, and it ages well as you add new third-party tags over time. Review the policy whenever you add an embedded service, since a new widget may quietly need a feature your current header blocks.

How to check your Permissions-Policy

Because the header runs silently in the browser, the reliable way to confirm it is to inspect your live responses. Run a security scan with EzyAudit AI and you will see whether Permissions-Policy is present and whether it sensibly limits the features your site exposes, alongside every other security header. Our overview of website security headers explained shows how it fits the bigger picture, and the features page lists everything we test. For the full feature list and syntax, see the MDN reference for Permissions-Policy.

A tuned Permissions-Policy quietly removes capabilities attackers rely on and keeps your users’ devices private. Scan your website now to see which features your pages currently allow.