Skip to content

Permissions-Policy: Switch Off What You Don't Use

Camera, mic, geolocation - your site grants browser powers it never uses. A minimal Permissions-Policy that shuts them off without breaking anything.

Smartphone showing a chat conversation

Short answer

Permissions-Policy (formerly Feature-Policy) lets you turn browser features off for your origin. If you do not use the camera, microphone, geolocation, or payment APIs, deny them in one header so a compromised script cannot flip them on.

Why this header exists

Modern browsers expose powerful APIs to JavaScript: camera, microphone, geolocation, USB, payment requests, and more. Most marketing sites and SaaS dashboards never need half of them.

Leaving them available is free attack surface for any script that ends up running on your page - first party or third party. Permissions-Policy is the allowlist (and denylist) for those features.

A minimal policy that rarely breaks anything

Start by denying features you know you do not use: camera=(), microphone=(), geolocation=(), payment=(), usb=(). Empty parentheses mean nobody, not even this origin.

If a product page needs geolocation later, open it deliberately for your origin only: geolocation=(self). Do not open features "just in case."

How to roll it out safely

Ship the header on staging first. Click through login, checkout, file upload, and any embedded map or video call. If something needs a denied feature, the browser console will usually say so.

Then ship to production and re-scan so the header shows up in your grade. One-line change for most reverse proxies and CDNs.

Pair it with the rest of the set

Permissions-Policy does not fix missing HSTS, open framing, or mixed content. Treat it as one row in the same deploy as CSP, HSTS, nosniff, and Referrer-Policy.

The five-header baseline still carries most of the weight; this one closes a modern gap those five do not cover.

Config to copy

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

Paste carefully. Test on staging first if the setting can lock users out.

What to do this week

  1. List browser features your product actually uses.
  2. Deny the rest with Permissions-Policy at the edge.
  3. Click through critical flows on staging.
  4. Verify the header on production with curl -I and a re-scan.

One header. Features you never use stay off - even if a script asks.

Run a free security grade on your domain · Pricing

Update log (1)

2026-05-09Editorial form rewrite for length and uniqueness.

Sources + verification

Practical guidance based on mainstream browser behavior, common reverse-proxy configuration, and widely published RFCs and vendor docs. Verify on your own stack with curl, browser devtools, and a re-scan after each change.

Keep reading

Tooling The five headers that fix most of a failed scan 2026-05-06 Tooling Content Security Policy Explained (Without Tears) 2026-05-02 Tooling Add Security Headers: Nginx, Apache & Cloudflare 2026-05-04