# Permissions-Policy (/en/docs/web-security/policies/permissions-policy)



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.

<Callout type="info" title="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.
</Callout>

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

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

## How Permissions-Policy works [#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 [#how-to-configure-permissions-policy]

```http
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 [#report-only-mode]

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

```http
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 [#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 [#insecure-configurations-to-avoid]

<Callout type="warn">
  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.
</Callout>

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

## Known bypasses and limitations [#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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy)
header (see [legacy security headers](/en/docs/web-security/policies/legacy-headers)).

## Risks [#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 [#recommendation]

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

The [OWASP HTTP Headers cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)
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 [#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](/en/docs/web-security/reporting-api/reports/permissions-policy-violation).
CentralCSP collects the [stream](/en/docs/platform/monitoring/permissions-policy).

## Browser support [#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 [#faq]

### What does Permissions-Policy do? [#what-does-permissions-policy-do]

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.

### What is the difference between Permissions-Policy and Feature-Policy? [#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.

## See also [#see-also]

* [permissions-policy-violation report](/en/docs/web-security/reporting-api/reports/permissions-policy-violation)
* [Legacy security headers](/en/docs/web-security/policies/legacy-headers)
* [Reporting-Endpoints header](/en/docs/web-security/reporting-api/headers/reporting-endpoints)
* [Permissions-Policy explained](/en/blog/permissions-policy-explained)
* [Permissions-Policy monitoring in CentralCSP](/en/docs/platform/monitoring/permissions-policy)

## Sources [#sources]

* [MDN, Permissions-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Permissions-Policy)
* [W3C, Permissions Policy](https://www.w3.org/TR/permissions-policy/)
* [caniuse, Permissions Policy](https://caniuse.com/permissions-policy)
* [OWASP HTTP Headers cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)