By · Updated

Permissions-Policy Builder

Block or Allow Camera, Microphone, Geolocation and Payment per Origin, With Server Config

No ratings yet

OneTask is free, with no sign-up, and built by one person.
If this tool saved you time, a coffee helps keep new ones coming.

How the Permissions-Policy Builder works

This Permissions-Policy builder writes the HTTP header that decides which browser features your pages and the frames inside them may use. Pick block, self or listed origins for each feature and copy the header with ready-made nginx, Apache and Netlify lines.

What the permissions-policy builder sets

Permissions-Policy lets a site switch off powerful browser APIs it does not need, so an injected script or an embedded advert cannot ask for the camera, read the clipboard or track location. Each feature takes an allowlist: () blocks it everywhere, (self) allows your own origin, (self "https://pay.example.com") adds named origins and * allows any origin.

Features are blocked or allowed for the whole page tree. A cross-origin iframe also needs the matching allow attribute, such as allow="payment", before the browser lets it use a feature the header permits. The builder prints that attribute when you allow listed origins.

The last option blocks a group of rarely needed APIs: motion sensors, MIDI, serial, HID, Bluetooth, WebXR, encrypted media and the Topics advertising API. Browsers ignore feature names they do not know, so a long header is harmless.

FAQ

What replaced the Feature-Policy header?

Permissions-Policy replaced Feature-Policy with a structured-header syntax, so feature=() instead of feature 'none'. Chrome and Edge only read the new header, so rename any old Feature-Policy header and rewrite its values with this builder.

Will blocking a feature break my own site?

Only if your pages use it. Blocking the camera on a site with no video calls changes nothing for visitors. Check your own features first, set those to Self only, and watch the browser console for permissions policy violation messages after deploying.

Why does Self and listed origins need an origin?

That option adds each listed origin to the allowlist after self, so it needs at least one full origin such as https://pay.example.com. Paths are not allowed because the policy works per origin, not per page.

See also: all Security & Identifiers tools, Dev Utilities, Formatters & Validators, Data & Encoding, SEO, Accessibility, AI.

Related tools

Security Headers Generator

Generate HTTP security headers for nginx, Apache, Netlify and Express.

Security Headers Checker

Check pasted response headers for missing, weak and leaky security headers.

CSP Builder

Build a Content-Security-Policy header from per-directive source lists.

Referrer Policy Explainer

See the Referer each Referrer-Policy value sends from your page.

.env File Checker

Lint a .env file for syntax errors, duplicates and weak secrets.