Permissions-Policy Header: Turn Off Powerful Browser Features

The Permissions-Policy header (formerly Feature-Policy) tells the browser which powerful features your document and its embeds may use. If your marketing site never needs the camera or microphone, disable them centrally so a injected script or third-party iframe cannot prompt for them either.

This guide gives a practical baseline, notes on third-party embeds, and verification tips via a security scan.

A sensible baseline

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

Empty allow-lists (=()) mean the feature is disabled for the top-level document and nested contexts unless you later add origins. Start strict on brochure sites; loosen only where a product flow needs the API.

Common directives to consider

• camera / microphone - disable unless you ship video calling or recording.
• geolocation - disable unless a store-locator or map flow needs it.
• payment - disable unless you use the Payment Request API.
• usb / bluetooth / midi - usually off for public websites.
• fullscreen / autoplay - tune based on marketing video behaviour.

Allow-listing a trusted embed

Permissions-Policy: geolocation=(self "https://maps.example.com")

Rollout advice

1. 1Inventory features your first-party code actually calls.
2. 2Deploy a strict policy on staging and click through login, checkout, and support chat.
3. 3Add exceptions only for broken flows.
4. 4Promote to production and verify with DevTools Application/Permissions probes plus an automated header grade.

Permissions-Policy is least-privilege for browser APIs. Combine it with Referrer-Policy and the rest of your HTTP security headers baseline, then keep the allow-list in code review so new widgets cannot silently re-enable the camera for the whole site.