Technical
Permissions-Policy
Also called Feature-Policy.
Permissions-Policy is an HTTP response header that switches browser features such as camera, microphone, and geolocation on or off for a page and its embedded frames. It replaced the older Feature-Policy header.
How it is measured
Run `curl -I` and read a value like `Permissions-Policy: camera=(), microphone=(), geolocation=(self)`. An empty `()` denies the feature everywhere, `self` allows the page's own origin, and quoted origins allow named third parties. Scanners list missing or misspelled directives.
DevTools prints a violation in the console when a blocked API is called or an iframe asks for a disallowed feature. For iframes also check the `allow` attribute on the tag.
Worked example
A marketing site embeds a video widget from a third party that asks for `geolocation` and `camera` for no clear reason. The team sends `Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()` for the whole site. A week later the console shows 12 blocked attempts a day from that iframe.
The contact page needs its own map to use location, so that one page sends `geolocation=(self)` while the rest stay locked.
How it differs
Permissions-Policy governs browser features, and CSP governs where content may load from. One decides whether a frame can ask for the camera, and the other decides whether the frame can load at all.
Common errors
Writing the old Feature-Policy syntax. Forgetting the commas between directives. Using `*` for everything. Denying a feature your own app needs. Assuming it blocks server-side use. Not thinking about iframes.
In practice
Start with deny-all for the features you do not use, then re-allow `self` where a page needs it, and check the console for new violations after deploy. Add the header at the CDN so it covers every page.