What is Permissions-Policy?

Browsers expose powerful capabilities to web pages: camera and microphone access, geolocation, the payment request API, sensors, screen capture, clipboard access, and more. Permissions-Policy, a W3C specification, lets a site declare which of those a document may use, and which of them it delegates to content it embeds. It replaces the earlier, differently spelled Feature-Policy header.

Syntax

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

Each feature is followed by an allowlist. An empty list () disables the feature entirely. self permits the document’s own origin, * permits everything, and specific origins may be named for embedded frames. Individual iframes can be restricted further with the allow attribute, which intersects with the page’s policy.

What it does and does not do

The header removes the ability to ask. A page under camera=() cannot prompt the user for camera access at all — the relevant API rejects. It is not a replacement for the user’s own permission decision: a feature that is allowed by policy still requires consent, and the user can still refuse or revoke it. So the header is a way of stating an application’s intent and constraining what code running in the page — including third-party scripts and embedded widgets — is capable of requesting.

That makes it primarily a defence-in-depth control for supply-chain and injection scenarios. If an injected or compromised script cannot invoke geolocation or screen capture, one avenue is closed even though the injection itself remains a serious problem in its own right. It also protects users of your site from overreach by embedded content you do not fully control, which pairs naturally with subresource integrity and a restrictive CSP.

Deploying it

Start by denying everything the application does not use, which for most sites is nearly the whole list, then grant back the few features that are needed and only to the origins that need them. Feature names and browser support vary, and unknown features in the header are ignored rather than treated as errors, so a policy can safely name features that not every browser recognises. Test embedded content after changing the policy, since payment widgets, video players and map embeds are the components most likely to depend on a delegated feature.

Like other header-based controls, it is applied per response, so it needs to reach every host in the estate rather than only the primary application.

Related concepts

See CSP, referrer policy, X-Frame-Options, clickjacking, least privilege and security headers.