Permissions-Policy Generator

Modern browsers give web pages access to powerful features: the camera and microphone, location, USB and Bluetooth devices, payment dialogs, motion sensors and more. Most sites need few or none of them, yet any script on the page, including a compromised library or an embedded advertisement, can ask for them. The Permissions-Policy response header lets you say up front which features your page, and the frames inside it, may use at all. It is the successor to the older Feature-Policy header.

The syntax

A policy is a list of directives separated by commas. Each is a feature name, an equals sign and an allowlist in parentheses. camera=() disables the camera for everyone. geolocation=(self) allows only your own origin. fullscreen=(self "https://video.example.com") allows your site and one named origin. payment=* allows every origin. The generator writes this syntax for you from a list of dozens of features, each with a one-line description of what it controls.

The five choices

For every feature you choose between default, nothing, own site only, everyone and custom origins. Default leaves the feature out of the header, so the browser’s built-in rule applies. Nothing writes an empty list and removes the feature from your page and every frame. Own site only writes self. Everyone writes the wildcard. Custom origins lets you type the origins that are allowed, for instance a payment provider’s domain.

A worked example

Press “Sample: switch off sensors, media and payments”. The page sets 17 features to nothing: camera, microphone, geolocation, payment, USB, serial, HID, Bluetooth, MIDI, display capture, accelerometer, gyroscope, magnetometer, ambient light sensor, XR spatial tracking, browsing topics and interest cohort. The header grows to a single line that begins camera=(), microphone=(), geolocation=() and continues through the others. For a content site, a blog or a documentation page this is a good starting point, since none of those features is needed, and it removes the permission prompts a malicious script could trigger.

The iframe allow attribute

The same idea applies to frames you embed. A frame gets a feature only if the parent policy allows it for the frame’s origin and the allow attribute on the iframe grants it, for example allow="camera; microphone". The page generates the matching attribute for the origins you list, so the header and the markup stay consistent when you embed a video call widget or a payment form.

Browser support

Chromium-based browsers recognise the largest set of feature names. Others ignore names they do not know, so a long policy does no harm, though some protection exists only where the feature exists. Features such as browsing topics and interest cohort relate to Chrome’s advertising proposals. Check support for any single feature before relying on it as a security control.

Limits

The header limits what the browser lets pages do. It does not stop a user from granting permissions to your own origin when you allow self. The older Feature-Policy header is deprecated, and the page writes Permissions-Policy only.

Related tools

• Security Headers Generator and Auditor includes this header in its checks.
• COOP and COEP Header Generator handles the cross-origin isolation headers.
• CSP Generator and Evaluator controls where content may load from.
• HSTS Header Generator completes the basic header set.