Permissions-Policy
What is Permissions-Policy?
Permissions-PolicyAn HTTP response header (formerly Feature-Policy) that lets a site declare which browser features — camera, microphone, geolocation, payment, USB, sensors — its own document and any embedded iframes are allowed to use.
Permissions-Policy is the successor to the Feature-Policy header, standardized to a structured-headers syntax and supported by all major browsers. It lets a document express, per powerful feature, who is allowed to use it: the document itself (`self`), specific origins, or no one. A header like `Permissions-Policy: geolocation=(), camera=(self), payment=(self "https://checkout.example")` denies geolocation everywhere, lets the main document use the camera, and lets the document plus checkout.example use the Payment Request API. Permissions-Policy is enforced both for the top-level document and recursively for nested browsing contexts, with the parent able to restrict children further (but never expand their privileges). It is the simplest defense against third-party scripts or iframes silently probing for camera, microphone, geolocation, sensors, fullscreen, autoplay, USB, serial, HID, payment, and many other capabilities; modern hardening guides recommend setting it explicitly alongside CSP and HSTS.
● Examples
- 01
A SaaS dashboard sets `Permissions-Policy: geolocation=(), microphone=(), camera=()` to deny location and media APIs to itself and every embedded widget.
- 02
An embed-host site grants Payment Request only to a known payments iframe by using `payment=(self "https://pay.example.com")`.
● Frequently asked questions
What is Permissions-Policy?
An HTTP response header (formerly Feature-Policy) that lets a site declare which browser features — camera, microphone, geolocation, payment, USB, sensors — its own document and any embedded iframes are allowed to use. It belongs to the Application Security category of cybersecurity.
What does Permissions-Policy mean?
An HTTP response header (formerly Feature-Policy) that lets a site declare which browser features — camera, microphone, geolocation, payment, USB, sensors — its own document and any embedded iframes are allowed to use.
How does Permissions-Policy work?
Permissions-Policy is the successor to the Feature-Policy header, standardized to a structured-headers syntax and supported by all major browsers. It lets a document express, per powerful feature, who is allowed to use it: the document itself (`self`), specific origins, or no one. A header like `Permissions-Policy: geolocation=(), camera=(self), payment=(self "https://checkout.example")` denies geolocation everywhere, lets the main document use the camera, and lets the document plus checkout.example use the Payment Request API. Permissions-Policy is enforced both for the top-level document and recursively for nested browsing contexts, with the parent able to restrict children further (but never expand their privileges). It is the simplest defense against third-party scripts or iframes silently probing for camera, microphone, geolocation, sensors, fullscreen, autoplay, USB, serial, HID, payment, and many other capabilities; modern hardening guides recommend setting it explicitly alongside CSP and HSTS.
How do you defend against Permissions-Policy?
Defences for Permissions-Policy typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for Permissions-Policy?
Common alternative names include: Feature-Policy (legacy), Permission policy.
● Related terms
- appsec№ 237
Content Security Policy (CSP)
An HTTP response header that tells the browser which sources of scripts, styles, frames and other content are allowed, limiting the impact of XSS and data-injection attacks.
- appsec№ 552
HTTP Security Headers
Response headers that instruct browsers to enforce defensive behaviour such as HTTPS-only, framing restrictions, content policies and referrer controls.
- appsec№ 263
Cross-Origin Opener Policy (COOP)
An HTTP response header that lets a document opt into a process-isolated browsing context group, preventing cross-origin windows from inspecting or manipulating it via `window.opener` and friends.
- appsec№ 262
Cross-Origin Embedder Policy (COEP)
An HTTP response header that forces every cross-origin subresource a document loads to explicitly opt in via CORS or CORP, completing the cross-origin isolation prerequisites alongside COOP.
- appsec№ 574
iframe sandbox
HTML attribute that applies extra restrictions to an iframe's content, blocking scripts, forms, navigation, and same-origin access unless explicitly re-enabled.
- appsec№ 1302
Trusted Types
Browser API and CSP directive that prevents DOM-based XSS by requiring dangerous DOM sinks to receive typed, policy-vetted values instead of raw strings.