Permissions-Policy Header Explained
The Permissions-Policy HTTP response header lets a site declare which browser features — camera, microphone, geolocation, and dozens more — a page and any content it embeds are allowed to use. By switching off features a page does not need, it shrinks the attack surface: a compromised third-party script or embedded iframe cannot silently reach for the camera or location if the policy forbids it.
What is the Permissions-Policy header?
Permissions-Policy is the successor to the older, now-deprecated Feature-Policy header. It follows the principle of least privilege for browser capabilities: instead of leaving every powerful API available to every script on the page, you allowlist only the features you actually use, and only for the origins that should have them.
How the syntax works
Each directive names a feature and an allowlist of origins. An empty list () disables the feature entirely; (self) allows only the page's own origin; specific origins can be listed explicitly.
| Fragment | Meaning |
|---|---|
camera=() | No one may use the camera, not even this page. |
geolocation=(self) | Only this origin may request location. |
microphone=() | Microphone access is fully disabled. |
fullscreen=(self) | Only this origin may trigger fullscreen. |
Example Permissions-Policy header
Permissions-Policy: camera=(), microphone=(), geolocation=(self), fullscreen=(self)This disables camera and microphone completely, allows geolocation and fullscreen only for the site itself, and — because they are not listed — leaves other features at their browser defaults.
Why it matters
- Contains third-party code. Ad networks, widgets, and embedded iframes cannot invoke sensitive APIs you have switched off.
- Limits the blast radius of XSS. Even if a script is injected, it cannot access a feature the policy disables.
- Protects users from surprise prompts. Disabling unused features means no unexpected camera or location requests.
How to check Permissions-Policy
Inspect a site's Permissions-Policy with the free HTTP headers checker, or see it alongside every other header in the security headers guide.
Common mistakes
- Confusing it with feature permissions prompts. Permissions-Policy governs whether a feature is available at all; it does not replace the browser's user-consent prompt for features that remain allowed.
- Still using
Feature-Policy. That header is deprecated; migrate to Permissions-Policy syntax. - Leaving everything enabled. Explicitly disabling unused features is the whole benefit — an absent header means browser defaults apply.
Related security headers
Permissions-Policy complements the content and transport headers: Content-Security-Policy, HSTS, and Referrer-Policy.
Frequently asked questions
What is the difference between Permissions-Policy and Feature-Policy?
They do the same job, but Feature-Policy is the older, deprecated name with slightly different syntax. Permissions-Policy is the current standard — use it instead.
Does Permissions-Policy replace the browser permission prompt?
No. It decides whether a feature is available to the page at all. For features that remain allowed, the browser still asks the user for consent when needed.
Which features should I disable?
Disable everything your site does not use — commonly camera, microphone, geolocation, and payment — and restrict the rest to self. This limits what any third-party or injected code can reach.