Permissions-Policy Builder
Pick browser feature permissions (camera, geolocation, mic…) to build a Permissions-Policy header.
The Permissions-Policy header (formerly Feature-Policy) controls which origins are allowed to use powerful browser features such as the camera, microphone, and geolocation. By disabling everything by default and allowing only what you truly need, you sharply reduce the risk of third-party scripts or iframes invoking sensitive capabilities without the user's consent.
This builder lets you set 12 features — camera, microphone, geolocation, payment, USB and more — to disabled, same-origin only, or all origins, and instantly produces a ready-to-paste Permissions-Policy header string. To design your content security policy too, use the CSP generator, and to verify the live response headers afterward, run the security headers check.
Set each browser feature to disabled, same-origin, or all origins.
cameramicrophonegeolocationfullscreenpaymentusbautoplayaccelerometergyroscopemagnetometerdisplay-captureclipboard-writePermissions-Policy: camera=(), microphone=(), geolocation=(), fullscreen=(self), payment=(), usb=(), autoplay=(self), accelerometer=(), gyroscope=(), magnetometer=(), display-capture=(), clipboard-write=()
Leaving unused features Disabled () is the safe default.
Allowlist syntax
The parentheses after each feature name list the origins permitted to use it. This builder offers three common settings.
()— empty list. Disables the feature for every origin, including the page itself.(self)— allows only the same origin; third-party iframes remain blocked.*— allows every origin. This is the loosest setting, so use it only when necessary.
Example output
For instance, to block camera, microphone, and geolocation while allowing fullscreen only for your own origin, the header looks like this:
Permissions-Policy: camera=(), microphone=(), geolocation=(), fullscreen=(self)
Add the header to your web server (nginx, Apache), CDN response headers, or the Next.js headers()config. Features you do not list fall back to the browser default (usually allowed), so for security it is safest to explicitly disable unused features with ().
Recommended defaults by feature
These are sensible starting points for most sites. If you do not actually use a feature, lock it down with ()and open up only the ones you need — a “deny by default” posture.
| Feature | Recommended default | Example directive |
|---|---|---|
| camera | Disable unless needed () | camera=() |
| microphone | Disable unless needed () | microphone=() |
| geolocation | Same-origin if used (self) | geolocation=(self) |
| fullscreen | Same-origin (self) | fullscreen=(self) |
| payment | Disable unless using Payment Request () | payment=() |
| usb | Disable () | usb=() |
| autoplay | Same-origin (self) | autoplay=(self) |
| display-capture | Disable () | display-capture=() |
Worked example: a site that embeds no media
Imagine a static marketing site or blog that never touches the camera, microphone, geolocation, or payment APIs. The safest move is to lock every sensitive feature behind an empty list ().
- Input (intent): we use none of these powerful features, so block them all.
- Generated header:
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=() - Reading it:
()means blocked for every origin, including the page itself;(self)means allowed only on the same origin (third-party iframes stay blocked); and*means allowed for every origin.
With this header in place, a sneaky ad iframe or third-party script cannot turn on the visitor's camera or microphone or read their location — the browser refuses the call outright. If you later add a video consultation feature, simply open that one capability to your own origin with camera=(self). After deploying, confirm the header actually ships on the response with the security headers check.