Safeguard
Security Guides•

Permissions-Policy header: turn off browser features you never use

Permissions-Policy lets a page disable camera, microphone, geolocation and more for itself and its iframes. Syntax, allowlists and how it pairs with allow.

Safeguard Security Team
3 min read

Permissions-Policy is a response header that decides which browser features a page and its embedded frames may use. If your site never needs the camera, microphone or geolocation, disable them with an empty allowlist. A third-party iframe then cannot ask for them either.

The syntax

Each directive is a feature name followed by an allowlist in parentheses. Directives are separated by commas.

Permissions-Policy: camera=(), microphone=(), geolocation=(self "https://maps.example.com")

The allowlist values:

  • An empty list, written as (), disables the feature in the page and in every nested frame.
  • self allows the page and same-origin frames only.
  • A quoted origin allows that origin. You can list several.
  • The star allows everything, and must be used alone.

Wildcard subdomains are supported where browsers allow them, but a pattern for all subdomains of example.com does not match example.com itself. List both if you need both.

Why it helps with third-party content

Embedded widgets run in your page. Without a policy, a frame can request powerful features if the user clicks allow. A header that denies those features sets an upper bound that the frame cannot raise.

The header and the iframe allow attribute work together. A feature works in a frame only if the parent policy permits that frame's origin and the allow attribute grants the feature. MDN's advice is to set the widest acceptable policy in the header and narrow it per frame.

<iframe src="https://video.example.com/embed" allow="fullscreen"></iframe>

Common starting points

Pick features you know you do not use. A content site might disable camera, microphone, geolocation and payment, and leave fullscreen on for its video embed.

When a disabled feature is called, the browser fails the call. For example, getUserMedia rejects with NotAllowedError and geolocation callbacks receive a permission denied error. Test pages that embed video or maps before shipping, since a missing allowlist entry shows up as a broken embed.

Reporting

You can send violation reports to an endpoint defined in a Reporting-Endpoints header.

Reporting-Endpoints: default="https://example.com/reports"
Permissions-Policy: geolocation=()

Caveats

MDN marks the header as experimental and not Baseline, because some major browsers do not support it. Treat it as defense in depth, not your only control. MDN also notes an inconsistency in quoting of self inside the allow attribute, so verify in the browsers you support.

Quick check

Does Permissions-Policy replace the permission prompt?

No. It restricts whether a feature is available at all. Where a feature is allowed, the browser still asks the user.

Is it the same as Feature-Policy?

It is the successor name for the same idea. Use Permissions-Policy and check the compatibility table for the browsers you support.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.