Permissions-Policy, control features and report violations

Permissions-Policy allows or denies browser features like camera, microphone, and geolocation per document and per frame.

Permissions-Policy lets a site decide which browser features and APIs may be used, in the top document and in embedded frames. You can switch off geolocation, camera, microphone, and many other features outright, or allow them only for specific origins, which shrinks the attack and privacy surface a page and its third parties can reach.

Limited availability

The Permissions-Policy header is Chromium-only (Chrome and Edge), and browser-compat data still marks it experimental. Firefox and Safari support only the iframe allow attribute model for some features. Sending the header is still worth it as defense in depth; browsers that do not support it ignore it harmlessly.

The OWASP baseline denies the three most privacy-sensitive features outright:

Permissions-Policy: geolocation=(), camera=(), microphone=()

How Permissions-Policy works

The header is a comma-separated list of directive=allowlist entries, where the directive is a feature name and the allowlist says which origins may use it. An empty allowlist disables the feature everywhere; (self) limits it to your own origin.

How to configure Permissions-Policy

Permissions-Policy: geolocation=(), camera=(self)

Allowlist	Status	Meaning
`*`	❌ Risky	Every origin, including third-party frames, may use the feature.
`()`	✅ Good	The feature is disabled everywhere.
`(self)`	✅ Good	Only your own origin may use it.
`(src)`	✅ Good	In an iframe `allow` context, the frame's own origin.
`("https://a.example")`	✅ Good	Explicit quoted origins (space-separated; combine with `self`).
`("https://*.example.com")`	✅ Good	A wildcard origin covering subdomains.

* and () must appear alone. The example above disables geolocation entirely and allows the camera only on your own origin.

The features most worth restricting are the powerful, privacy-sensitive ones: camera, microphone, geolocation, fullscreen, payment, usb, display-capture, and autoplay, plus the advertising opt-outs browsing-topics and interest-cohort.

Report-only mode

Reporting-Endpoints: pp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

Permissions-Policy-Report-Only: geolocation=();report-to=pp-endpoint

Report-Only surfaces which features would be blocked before you enforce, so you do not break a legitimate use of a feature in a frame.

What it protects against

Unwanted feature use, by your own page or, more often, by a third-party frame: camera, microphone, geolocation, payment, and similar powerful APIs. Restricting them reduces both privacy exposure and the surface an attacker (or a careless third party) can reach.

Insecure configurations to avoid

Granting a feature with * allows every origin, including third-party frames, to use it. Prefer () to disable, or (self) to scope to your own origin.

Default to denying features you do not use, and add origins only as you need them.

Known bypasses and limitations

The header itself is not enforced outside Chromium: Firefox and Safari implement only the iframe allow attribute model for some features, so it is not yet a fully cross-browser control. Treat the header as defense in depth on Chromium and use the iframe allow attribute for the cross-browser cases. Permissions-Policy is the standardized successor to the deprecated Feature-Policy header (see legacy security headers).

Risks

Over-restricting can break a legitimate feature in a frame you forgot about (an embedded map needing geolocation, a video call needing the camera). Test with Report-Only and watch the violations before enforcing.

Recommendation

Permissions-Policy: geolocation=(), camera=(), microphone=()

The OWASP HTTP Headers cheat sheet recommends denying the powerful features you do not use, starting with geolocation, camera, and microphone. Extend the list to the other features above as your page allows, and grant an origin only when a specific frame needs it.

Reporting

A per-directive report-to= parameter routes that feature's violations to a named endpoint, and the browser emits the permissions-policy-violation report. CentralCSP collects the stream.

Browser support

A W3C standard, but the header is Chromium-only (Chrome and Edge, with partial feature coverage), and browser-compat data marks it experimental. Firefox and Safari support only the iframe allow attribute model for some features. Reporting is Chromium-only too.

FAQ

What does Permissions-Policy do?

What is the difference between Permissions-Policy and Feature-Policy?

They are the same mechanism under two names. Permissions-Policy is the standardized successor to the deprecated Feature-Policy header, which was its former name. Use Permissions-Policy going forward, and reach for the iframe allow attribute for the cross-browser cases the header does not yet cover outside Chromium.

Permissions-Policy