Headers

Permissions-Policy: explicitly disabling browser features your site doesn't use.

Published 2026-05-06 · Last updated 2026-05-06 · Vantyris editorial

What this means for your business

• Without it, any JavaScript on your page can request access to powerful browser APIs. Most of them (camera, microphone, geolocation) need the user's consent before they switch on, but the request itself is a phishing vector. A malicious script can pop up a permission dialog that looks like it came from your site.
• Permissions-Policy lets you tell the browser 'this site never uses these features, refuse them outright'. A compromised third-party script then can't even ask. The browser blocks the request before the user ever sees a permission dialog.
• Setting interest-cohort=() in the header also disables interest-cohort tracking (the FLoC successor). It's part of Vantyris's standard defensive header set, and it's what the Vantyris homepage ships.

How to fix

Add a Permissions-Policy header to every page's response, listing the features to disable. Start by disabling everything you don't actively use.

1. List the browser APIs your site actually needs. Audit the JavaScript on your site for calls to navigator.geolocation, navigator.mediaDevices.getUserMedia, navigator.usb, navigator.bluetooth, or similar. Most small business sites make none.
2. Write the Permissions-Policy header. A defensive starting policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=(). Each feature followed by =() means 'block everywhere'. To allow a feature on your own origin, use geolocation=(self). For specific third-party origins, use geolocation=(self "https://maps.example.com").
3. Add the header to your web host or CDN. Apache: Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()". Nginx: add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()" always;. Next.js: in the headers function in next.config.mjs.
4. Verify in DevTools. Reload your site, open the Network tab, click any request and look at Response Headers. You should see permissions-policy: camera=(), microphone=(), ....

Owner: Your web host or developer. · Time: 10-15 minutes.

Common gotchas

• If you DO use a feature (e.g., a 'show me on the map' button that uses geolocation), don't blanket-disable it. Use geolocation=(self) to allow your own domain.
• Some payment iframes (Stripe, PayPal) need payment allowed for specific origins. If you embed Stripe Checkout, set payment=(self "https://checkout.stripe.com").
• The syntax is finicky. Spaces inside parentheses, no quotes around feature names, exact origin URLs. Use a header checker (securityheaders.com) to validate.
• Older browsers read the now-deprecated Feature-Policy header instead. You can send both for belt-and-braces coverage. Most sites send only Permissions-Policy and accept that pre-2021 browsers won't enforce it.

How to verify the fix

A Vantyris verified scan checks that Permissions-Policy is present and parses the directives. securityheaders.com also grades how much the header covers.

Cyber Essentials alignment

This finding informs the following Cyber Essentials control areas (the UK government's baseline scheme, a sound checklist in any country):

• A2. Secure configuration: devices and services hardened against the weaknesses they ship with by default.

Vantyris is not a CE certifying body. The mapping above is informational.

Common follow-up questions

References

• MDN: Permissions-Policy MDN
• W3C: Permissions Policy Vendor
• OWASP secure-headers project OWASP

Related explainers

• Content Security Policy: the header that stops most XSS attacks dead.
• X-Frame-Options and frame-ancestors: the anti-clickjacking header.
• HSTS: the security header that locks HTTPS on for good.