Permissions-Policy Builder
Compose a Permissions-Policy header from feature + allowlist pairs.
Overview
The Permissions-Policy Builder composes a Permissions-Policy HTTP header from features (camera, microphone, geolocation, fullscreen, payment, accelerometer, autoplay, and dozens of others) and their allowlists (self, () for none, * for all, or specific origins). Output is the comma-separated structured header browsers expect.
Useful for security engineers and developers learning how to set Permissions-Policy to disable features or how to allowlist origins for iframe permissions. Reach for it when hardening a site against unwanted feature use by your own scripts or embedded iframes, or fixing the deprecated Feature-Policy header.
How it works
The Permissions-Policy (formerly Feature-Policy) is defined as a structured-fields header per RFC 8941. Each feature gets an allowlist in parentheses: () empty for fully disabled, (self) for first-party only, (self "https://trusted.example") for first-party plus a specific origin, * for any embedded iframe.
Browsers consult the policy when JavaScript calls a sensitive API or when an iframe attempts to use one. Denied calls fail with a permission error. The builder emits the structured-header syntax precisely (no quotes around self, double-quotes around origins), since the spec is strict.
Examples
- Block all sensitive features →
camera=(), microphone=(), geolocation=(), payment=(). - First-party only →
geolocation=(self), camera=(self). - Allow a payment provider iframe →
payment=(self "https://pay.example.com"). - Disable autoplay everywhere →
autoplay=().
FAQ
Permissions-Policy vs CSP?
CSP controls what code can load and execute. Permissions-Policy controls what features that code can use. Both layered together is the modern hardening baseline.
What happens when a feature is denied?
The browser API throws or rejects. For instance, navigator.geolocation.getCurrentPosition immediately fails the error callback with a permission error.
Does this replace Feature-Policy?
Yes. Feature-Policy is deprecated and replaced by Permissions-Policy. Both can coexist for transition, but new builds should use Permissions-Policy only.
Can I report violations?
Yes. Combine with the Reporting API (Report-To and Reporting-Endpoints) to collect denied-feature events. The policy alone is silent in production.