What the Permissions-Policy does

How it works

Browsers give websites access to device features: camera, microphone, location, payments, full screen and more. For the sensitive ones, the browser asks the visitor for permission. But that request can also come from embedded content, such as an ad banner or a widget running in an iframe. If such a service is compromised, it can try to use those features in your page's name.

With the Permissions-Policy header you tell the browser which features are relevant on your site at all, and for whom. Whatever is switched off can be requested neither by your page nor by embedded content; the browser does not even ask the visitor.

The syntax is feature=(allowed):

• camera=() switches the camera off for everyone.
• geolocation=(self) allows location for your own site only.
• geolocation=(self "https://maps.example") also allows it for an embedded service.

What matters

• Switch off what you don't need. Camera, microphone and location are the important ones; most websites use none of them.
• Think of embedded services. If an embedded service uses a feature, it needs it in the policy and in the allow attribute of its iframe, a video call needing the microphone, for instance.
• The new syntax. Its predecessor Feature-Policy, with values like camera 'none', is no longer read by current browsers. Carry the rules over to Permissions-Policy.

How to set it up

A starting point that switches off camera, microphone and location:

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

Add other features your site does not need, such as payment=() or usb=(). The header is set in the web server, the application or through a header rule at your hosting provider or CDN, by you or your agency.

add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

Afterwards, check pages with maps, video calls or payment forms to make sure they still work.