Permissions-Policy Header
Lets you switch off or restrict powerful browser APIs — camera, microphone, geolocation and more — for your own pages and any embedded content.
Last updated August 9, 2026.
Severity when missing: Low — see the missing-header finding on the security headers checker.
What it does
Permissions-Policy (the successor to Feature-Policy) declares, per browser API, which origins may use it. Each directive names a feature — `geolocation`, `camera`, `microphone`, `payment`, `usb`, `fullscreen`, and dozens more — and an allow-list of origins, where `()` means nobody, including the page itself, can use that feature.
Why it matters
Most pages never need camera, microphone or geolocation access. Explicitly disabling APIs a page doesn't use removes them as an attack surface: a compromised third-party script or a malicious ad embedded in an iframe can't invoke a permission prompt for a capability the top-level page has already switched off. It's defense-in-depth rather than a fix for a specific vulnerability class, which is why it's a lower-severity finding.
Example header
Example only — this is not evidence from a live scan.
Permissions-Policy: geolocation=(), camera=(), microphone=()How to test for it
- Run `curl -sI https://example.com` and check for a `Permissions-Policy` header.
- Review the directive list against what the page actually needs — a video-conferencing page legitimately needs `camera` and `microphone`; most marketing and content pages need neither.
How to add it
Nginx
add_header Permissions-Policy "geolocation=(), camera=(), microphone=(), payment=()" always;Apache
Header always set Permissions-Policy "geolocation=(), camera=(), microphone=(), payment=()"Cloudflare
Rules → Transform Rules → Modify Response Header → set `Permissions-Policy` to your directive list.Verify the fix
After deploying the change, re-run a Nivaronix scan on your domain, or check with curl -sI https://your-domain.example, to confirm the header now appears in the response.
FAQ
What's the difference between Permissions-Policy and asking the user for permission?
Permissions-Policy operates before any permission prompt ever happens — it controls which browser APIs (camera, microphone, geolocation, and others) a page or its embedded frames are even allowed to request access to, at the browser level. A page blocked from an API by Permissions-Policy never gets to show the permission prompt at all, regardless of what the user would have chosen.
Why would I restrict an API my site doesn't even use?
Because a third-party script or an iframe embedded on your page inherits your page's permissions by default unless Permissions-Policy says otherwise. Explicitly disabling camera, microphone, or geolocation on a page that has no legitimate use for them closes off that access even if a compromised or malicious script tries to request it.
Does Permissions-Policy replace Feature-Policy?
Yes — Permissions-Policy is the successor to the older Feature-Policy header, with a similar directive syntax but a different, more restrictive default posture. Feature-Policy is deprecated; new deployments should use Permissions-Policy.
Can Permissions-Policy break embedded content like maps or video players?
It can, if the policy denies an API (like geolocation for a maps embed, or autoplay for a video player) that an embedded iframe actually needs to function. The fix is scoping the directive to allow that specific API for the iframe's origin, rather than disabling it site-wide — test embedded third-party content after any policy change.
Standards reference
MDN — Permissions-Policy. For exactly how Nivaronix evaluates this header during a scan, see the methodology page.