What is Permissions-Policy
Permissions-Policy (formerly Feature-Policy) controls which browser APIs (camera, mic, geolocation, FLoC) can be used on your site. Permissions-Policy is part of the browser-facing trust boundary. It shapes what the client is allowed to reveal, load, or trust before any backend incident response even starts.
If you are already working through Content Security Policy, this topic gives you the missing layer between the raw signal and the decision you have to make. For a live check, start with the CyberFurl security headers scan and then use the See the web security headers feature page to see where it fits in the wider CyberFurl workflow.
Why it replaced Feature-Policy
The rename from Feature-Policy to Permissions-Policy was not just cosmetic. It reflected a clearer model for deciding which browser features should be available to the document or embedded content at all.
Common features to lock (camera, microphone, geolocation, payment, USB, FLoC)
The best candidates to disable are the ones the site does not need. Camera, microphone, geolocation, payment handlers, USB, and similar features are valuable when required, but they should not be ambiently available just because the browser supports them.
Syntax
Permissions-Policy syntax expresses which origins, if any, are allowed to use a given browser capability. The practical goal is to make unnecessary capabilities unavailable by default and then grant them only where the real application needs them.
How to test
Testing is not only about confirming the header exists. It is about checking real browser behavior in pages and iframes that would otherwise request those capabilities. A policy with no behavioral validation is just another string in a response header.
- 1
Measure the live response surface
Capture the real headers, certificate chain, and browser-facing behavior that define Permissions-Policy in production. Development assumptions are not enough for internet-facing posture.
- 2
Tighten policy without breaking real traffic
Roll out the control in a staged way, especially if it changes browser execution, redirects, or certificate trust. The goal is durable enforcement, not a one-time header screenshot.
- 3
Validate in browser and scanners
Tools to check your Permissions-Policy
Use the CyberFurl security headers scan when you want to see the live signal on a real domain, and then step back to the See the web security headers feature page when you need the wider workflow around posture, monitoring, or remediation. That combination is usually much more useful than reading the standard in isolation.
Further reading inside CyberFurl
- CyberFurl security headers scan
- See the web security headers feature
- Content Security Policy
- CyberFurl public security report
Standards and references
Frequently asked questions
Permissions-Policy vs Feature-Policy?
Permissions-Policy is the successor to Feature-Policy. The rename came with syntax and model cleanup, but the operational goal stayed the same: decide which browser capabilities should be available to the page or embedded origins at all.
Does it work in iframes?
Yes. That is one of the main reasons it matters. A page can restrict what embedded content is allowed to do, which is useful when third-party widgets or partner frames should not inherit capabilities such as geolocation, camera, or fullscreen access by default.