Permissions Policy: define browser features for pages and embeddings

What Permissions Policy controls — and what it does not

Browsers offer web pages capabilities beyond displaying content: the camera and microphone, location, fullscreen, screen sharing, USB devices or the Payment Request API. Many are policy-controlled features. Each feature's specification defines a default allowlist. A Permissions Policy can restrict a feature for a document and selectively delegate it to embedded frames. W3C Permissions Policy: policy-controlled features

Two delivery mechanisms work together:

• The HTTP response header Permissions-Policy applies to the document it accompanies. It also limits what that document can delegate to embedded frames.
• The allow attribute on an iframe specifies which features the embedded content should receive.

The specification does not provide a variant using an HTML meta element. W3C: header and container policies, W3C: delivery

No header does not mean ‘everything allowed’. The camera, microphone, location, payment interface, screen capture, fullscreen and autoplay have the default allowlist 'self'. They are available to the top-level document and frames of the same origin; a cross-origin frame receives them only if the embedding document delegates them through allow. An absent header is therefore not evidence of an exploitable vulnerability. W3C: default allowlists, Media Capture and Streams: camera and microphone, Geolocation API

The Permissions specification explicitly describes the distinction from user permission: a feature can never become ‘granted’ through Permissions Policy, only through the person's consent or a browser rule. W3C Permissions: relationship to Permissions Policy, W3C: other and related mechanisms

This explains the security effect: a feature you block for the entire document, for example with camera=(), is also unavailable to a compromised or injected script in that document. Features your page uses itself remain available to any script running in your document's context. self means the document's origin, not ‘your own scripts’. Other measures address injected code, including safe output, Content Security Policy and Subresource Integrity.

The Web Security Check reads the Permissions-Policy header of the final retrieved response, checks its syntax and assesses whether selected features such as the camera, microphone and location are blocked or limited to the same origin. This snapshot does not cover allow attributes, Permissions-Policy-Report-Only, other pages or a browser's actual behaviour.

How the header and allow work together

Each document first receives an inherited policy. For the top-level document, it follows from the default allowlists. In a frame, it follows from the embedding document's policy and the iframe's allow attribute. A document's own header can then only restrict features further. A frame cannot use its own header to reopen something the embedding document has blocked. W3C: inherited policies, W3C: create a policy from a response

For a cross-origin frame and features with the default allowlist 'self', the embedding document's header must not exclude the frame's origin, and the iframe must delegate the feature through allow. The embedding document itself must also be eligible to receive the feature; a list containing only the other origin is insufficient. The frame's own header or a restriction higher up the frame chain can also deny the feature. These conditions concern policy; secure contexts, user permissions and other API prerequisites still apply. W3C: inheritance in a container

Browser support differs substantially. According to MDN compatibility data retrieved on 27 September 2026, Chrome has processed the Permissions-Policy header since version 85; Chromium-based browsers such as Edge follow this implementation. Firefox and Safari do not support the header. Chrome has recognised the allow attribute since version 60, Firefox since 74 and Safari since 11.1, each with its own list of supported features. For Safari, the data lists, for example, camera, microphone and display-capture in the attribute, but not geolocation or payment. MDN compatibility data: Permissions-Policy, MDN compatibility data: iframe allow

Which features you can control

The following selection covers common questions. The working group maintains a non-normative list of standardised, proposed and experimental features; no browser is required to support every one. W3C: feature list for the specification

Sources for the default allowlists: Media Capture and Streams, Geolocation, Payment Request, Screen Capture, Fullscreen, HTML: autoplay, WebUSB: Permissions Policy

The table is not a template. Whether () or permission is appropriate depends solely on whether your document or an embedding actually needs the feature. For example, restricting autoplay with autoplay=(self) prevents video players embedded from other origins from receiving it even with allow="autoplay".

Write the header correctly

The value of Permissions-Policy is a Structured Field Dictionary under RFC 9651. Features are separated by commas, and each receives an allowlist. Feature names are lowercase; origins are strings in double quotes. W3C: structured header serialisation, RFC 9651: dictionaries

According to MDN compatibility data, subdomain wildcards have been supported only since Chrome 108. Different subdomains and ports are different origins; https://www.example.com does not cover https://shop.example.com. W3C: examples

The following model suits a website that neither uses any of these features itself nor needs to delegate them to an embedding. It is a header example, not a tested template for your application:

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

Further observations from that test, consistent with the rules:

• The browser ignores unknown feature names individually; the remaining entries continue to apply.
• Chromium rejected unquoted origins, such as (self http://localhost:PORT), as an invalid entry with a console warning. The frame did not receive the feature.
• none is not a header keyword. Chromium reported geolocation=none as invalid and treated the allowlist as empty. Use () to block a feature.
• Multiple header lines are combined into a list. If two lines name the same feature, the last value applies. If both the application and CDN set the header, the order in the delivered response therefore decides the result. RFC 9651: parsing dictionaries

The allow attribute uses different syntax: semicolons separate features, keywords use single quotes, and origins are unquoted. Without an allowlist, 'src' applies, meaning the origin of the URL in the src attribute. W3C: HTML attribute serialisation, W3C: the allow attribute

<iframe src="https://maps.example.com/embed" allow="geolocation"></iframe>
<iframe src="https://video.example.net/room" allow="camera; microphone; display-capture"></iframe>

Introduce Permissions Policy in four steps

1. Inventory features and embeddings in use

Identify which features your own pages use and which features each embedded service needs: maps, video players, video conferencing, payment services, chat or support tools, login and identity services, and extensions in content management and shop systems. Record each embedding's exact origin, including subdomain and port.

Also decide which responsible output layer sets the header: application, web server, reverse proxy or CDN. Two layers independently adding values can easily produce conflicting entries. The article on implementation and architecture covers these responsibilities. Permissions Policy applies per document: if the same restriction should apply to every page, it must also accompany login, checkout and error documents.

2. Observe new restrictions first

In Chromium-based browsers, you can initially observe rules through Permissions-Policy-Report-Only. According to MDN compatibility data, this header has been available since Chrome 120; Firefox and Safari do not support it. In the documented local test, geolocation remained allowed under Permissions-Policy-Report-Only: geolocation=(); the browser generated a report labelled report. W3C: Report-Only header, MDN compatibility data: Report-Only

Reporting-Endpoints: pp-endpoint="https://reports.example.com/permissions-policy"
Permissions-Policy-Report-Only: camera=();report-to=pp-endpoint, microphone=();report-to=pp-endpoint, geolocation=();report-to=pp-endpoint

https://reports.example.com/permissions-policy is a placeholder for a receiver you operate; the header does not set one up. Reports may arise when a feature is attempted; the specification also provides reports about potential conflicts between frame delegation and inherited policy. A Report-Only policy does not override restrictions already enforced in parallel. An absence of reports therefore does not prove that no page or embedding needs the feature. The Reporting API guide explains delivery and assessment of reports. W3C: reporting

3. Block unnecessary features and selectively permit those needed

The following snippets show the configuration form for nginx and Apache. They have not been executed and assume that your pages do not need the listed features.

nginx: add_header operates in the http, server or location context. These directives are inherited only when the current level has no add_header directive of its own; since nginx 1.29.3, add_header_inherit can change this. Without always, nginx adds the header only for certain status codes, such as 200 or 301. A successful reload is required after the change. nginx: add_header

add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=()" always;

Apache: the snippet requires mod_headers; configuration in .htaccess must be permitted, for example through AllowOverride FileInfo. If the module is not loaded, Apache silently skips the contents of IfModule. always and the default onsuccess table are separate header lists; a header supplied by a backend may consequently arrive twice. Apache: Header directive

<IfModule mod_headers.c>
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=()"
</IfModule>

payment=() is appropriate only if neither your page nor an embedded payment service uses the Payment Request API. If an embedding needs a feature, permit it in both places. In the following model, only the video service is delegated camera and microphone access:

Permissions-Policy: camera=(self "https://video.example.net"), microphone=(self "https://video.example.net"), geolocation=()

<iframe src="https://video.example.net/room/123" allow="camera; microphone"></iframe>

https://video.example.net represents the embedded service's actual origin. If it redirects the frame to a different origin, permission does not automatically apply there.

4. Verify the effect and keep a rollback path

First check which header actually arrives. For an address you own and are authorised to check, the following command shows the headers of each response in a redirect chain; the final block belongs to the final response:

curl -sS -L -D - -o /dev/null https://www.example.com/

https://www.example.com/ is a placeholder; the command was not run against a real website. It shows an individual response, not browser behaviour.

In the browser, Chromium reports violations in the console, such as ‘Permissions policy violation: Geolocation access has been blocked …’, and identifies header parsing errors. Chromium exposes the effective-policy query under the older name document.featurePolicy, for example document.featurePolicy.allowsFeature('camera'). The specification calls the interface document.permissionsPolicy; in the documented Chromium 141 test, that name was absent. Also test required embeddings in Firefox and Safari, where only the allow attribute and the browsers' own defaults apply. W3C: policy introspection

Rollback is simpler than for HSTS: browsers do not store a Permissions Policy beyond the document. Removing or relaxing the header at the responsible output layer affects newly loaded documents. Cached HTML responses in a CDN, browser cache or service worker may still deliver the old header until refreshed, however. Plan to clear the relevant caches where necessary. The Cache-Control guide explains these caches.

Interpret findings correctly

An absent header shows only that the particular browser's default rules apply to this document. A present header shows which rules a supporting browser can apply to this response. Neither observation proves or disproves an exploitable vulnerability.

A Web Security Check finding concerns the header of one retrieved response at the time of retrieval. Whether embeddings work and which features are actually available in the browser can only be established through the browser checks in step 4.

Migrate from Feature-Policy

Permissions Policy was previously called Feature Policy. The old Feature-Policy header has different syntax and is deprecated. According to MDN compatibility data, Chrome has continued processing it since version 60; Firefox and Safari do not process it. W3C: introduction, MDN compatibility data: Feature-Policy

In the documented local Chromium 147 test, Feature-Policy: geolocation 'none' on its own still blocked geolocation. When both headers were present, the value from Permissions-Policy applied for each feature; the console reported the duplication. A feature listed only in the old header remained blocked. Chrome describes Feature-Policy as a lower-priority alias. Chrome for Developers: Permissions Policy

Account for a behavioural change during migration: under Feature Policy, an origin in the header list could be enough to give a cross-origin frame a feature. Under Permissions Policy, the frame also needs allow. Translate the old header, test affected embeddings, then remove Feature-Policy. The advanced headers guide discusses other deprecated headers.

Evidence and context

Permissions Policy is a technical measure restricting selected browser features. A present header is neither a universal legal requirement nor proof of compliance. When documenting the measure, record the tested URL, time, delivered header, affected embeddings and tested browsers.

Data protection principles such as data minimisation and data protection by default (Articles 5 and 25 GDPR, BfDI collection of legislation) concern the entire processing activity. Blocking a device interface can contribute, but does not replace assessment of the processing. For entities within the scope of Germany's BSIG, § 30 requires appropriate risk management measures; which headers form part of those measures follows from the organisation's risk assessment, not from the legislation. Permissions Policy is also neither a script inventory nor an inspection of included scripts' contents. The compliance overview and NIS2 checklist put these connections in context.

Related topics

To first see which header a publicly accessible page delivers, open the Web Security Check. It assesses an individual response; it does not replace the embedding and browser tests described above.