Permissions-Policy Header: Control Camera, Location and More

Short answer: Permissions-Policy is a response header that tells the browser which powerful features – camera, microphone, geolocation, payment, fullscreen, USB and others – your pages and any embedded iframes are allowed to use. A feature set to () is disabled everywhere on the page, (self) allows only your own origin, and listed origins allow specific partners. For a typical business site that uses none of these features, a header such as Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=() reduces what injected code or third-party embeds can request, with virtually no risk of breaking anything.

Modern browsers give websites access to far more than text and images. With the visitor’s permission, a page can use the camera and microphone, read the precise location, start payments, go fullscreen, access USB or Bluetooth devices and more. Most business websites use none of that – yet any script or iframe on the page could still ask. Permissions-Policy lets you declare up front which features your site actually needs and switch the rest off. It is a newer and less famous header than HSTS or CSP, but it is simple, safe and increasingly checked in security audits.

What problem Permissions-Policy solves

Every script and iframe on your page runs with some ability to call browser APIs. Usually that is fine, because browsers ask visitors before granting access to sensitive features. But permission prompts can still be abused. An injected script, a compromised advertising iframe or a malicious widget could request location or camera access on your site, and the prompt would show your domain name – visitors trust it because they trust you. Some features, such as autoplay, fullscreen or synchronous XHR, do not even need a prompt and can be misused to annoy visitors or degrade performance.

Permissions-Policy moves the decision to you. If the header says camera=(), no code on the page – yours, a plugin’s or a third party’s – can use the camera, and the browser will not even show a prompt. That removes an entire category of abuse and signals that your site only uses what it needs. The header was previously known as Feature-Policy; the older name and syntax are deprecated, so use Permissions-Policy for new configurations.

The syntax in plain words

The header is a comma-separated list of features, each followed by an allow-list in parentheses:

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

• feature=() – disabled for everyone, including your own pages.
• feature=(self) – allowed for your own origin; iframes from other origins are blocked unless listed.
• feature=(self "https://partner.example") – allowed for your origin and the listed origin, which must also be delegated in the iframe’s allow attribute.
• feature=* – allowed for any origin. Rarely a good idea.

Features you do not mention keep their browser default, which for many powerful features is “self only”. The MDN Permissions-Policy reference lists all features and their defaults and browser support.

Features worth considering

A safe starting policy

For a typical company website, blog or small shop without video calls, a store locator or hardware integrations, this is a sensible first version:

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), serial=(), bluetooth=(), display-capture=(), accelerometer=(), gyroscope=(), magnetometer=()

If your checkout uses the browser’s Payment Request API or wallet buttons, change payment=() to payment=(self) and add the payment provider’s origin if their iframe needs it. If you have a “find the nearest shop” feature using the browser’s location, use geolocation=(self). If you embed videos that should be able to go fullscreen, leave fullscreen out or allow the video provider’s origin.

How it works with iframes

Iframes are where Permissions-Policy is most useful. A feature can only be used inside an iframe if both conditions are met: your header’s allow-list includes the iframe’s origin, and the iframe element delegates the feature with its allow attribute, for example:

<iframe src="https://video.example/embed/123" allow="fullscreen; autoplay"></iframe>

Many embed codes from video, map and booking providers already include an allow attribute listing what they want. Read it before pasting: an embed that asks for camera or microphone access for no clear reason deserves a second look. With a strict header, even an over-permissive embed code cannot actually use features you have blocked.

How to add the header

Apache:

Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()"

Nginx:

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

Many CDNs and security plugins can add response headers too. As with other headers, set it in one place only, so two conflicting versions are not sent. After deploying, check it with curl -sI https://example.com | grep -i permissions-policy, and look at the browser console: blocked feature requests are reported there, which helps you notice anything you forgot to allow.

WordPress, shop platforms and hosted builders

On WordPress, the simplest route is adding the header at the server level – in .htaccess on Apache or LiteSpeed hosting, or in the Nginx configuration – because it then covers every page, including those generated by plugins. If you cannot edit server files, several security and header plugins let you set Permissions-Policy from the dashboard; choose one and avoid adding the same header through a second plugin or a CDN rule.

Hosted shop platforms and website builders vary. Some set a policy themselves, some allow custom headers in advanced settings, and some offer no control at all. In that case, check what the platform sends with curl -sI and, if the header is missing, ask the platform’s support whether custom security headers are possible. Where nothing can be changed, focus on what you can control: keep embeds and third-party scripts to those you trust, and review the allow attributes in embed codes before pasting them into pages.

For agencies managing many client sites, it helps to standardise one baseline policy and adjust it only for sites with maps, payments or video features.

Testing and common pitfalls

Because most sites use few of these features, breakage is rare, but it does happen in a few predictable places. Test these parts of the site after adding the header:

• Checkout and wallet buttons, which may use the payment feature inside provider iframes.
• Store locators and delivery-area checks that ask for the visitor’s location.
• Embedded videos – fullscreen and autoplay behaviour.
• Chat, support and video-call widgets that may request microphone or camera access.
• Admin areas of your CMS, which sometimes use features such as clipboard or fullscreen editing.

Other pitfalls: using the old Feature-Policy syntax with semicolons and spaces instead of the new comma-and-parentheses format; quoting self (it must be written without quotes, while origins must be quoted); and adding features that browsers do not recognise, which produces console warnings but no harm. Unknown features are simply ignored, so it is safe to include features that only some browsers support.

Where Permissions-Policy fits among the security headers

Permissions-Policy complements the other headers rather than replacing any of them. Content Security Policy controls where content may be loaded from; Permissions-Policy controls what that content may do with powerful browser features. X-Frame-Options or CSP frame-ancestors decide who may embed your pages; Permissions-Policy decides what pages you embed may use. HSTS protects the connection. Together they form a layered set of browser instructions that limit what can go wrong even when one piece of code on your page misbehaves. Among them, Permissions-Policy is usually the quickest win after the basics, because most sites can disable nearly everything it covers.

How Site AI Audit helps

Site AI Audit checks the security headers your site sends as part of every report, together with the SSL certificate, HTTPS redirect and exposed software versions. Missing headers are explained in plain words with a ready-to-use example and ranked by impact, so you can add the quick wins first. Run a free check to see which headers your site is missing.

Related reading

• HTTP Security Headers Explained: What Each One Does
• Referrer-Policy Header: Which Value to Use and Why It Matters
• Content Security Policy for Beginners: A Practical Setup Guide

The bottom line

Permissions-Policy lets you switch off powerful browser features your site does not use, for your own pages and for everything embedded in them. Start by disabling camera, microphone, geolocation, payment and hardware access unless you genuinely need them, allow the few features you do use for your own origin and named partners, and test checkout, maps and embeds. It is a short header with a clear benefit and very little risk.

FAQ

Is Permissions-Policy the same as Feature-Policy?

It is the renamed successor. Feature-Policy used a different syntax and is deprecated; new configurations should use the Permissions-Policy header with its comma-separated, parentheses-based format.

Will Permissions-Policy break my embedded YouTube videos?

Not if you allow what the embed needs. Leave fullscreen and autoplay at their defaults or allow the video provider’s origin, and keep the allow attribute from the embed code.

Does the header replace permission prompts?

No. For allowed features, the browser still asks the visitor for permission. The header only decides which features can be requested at all, and by which origins.

Do all browsers support Permissions-Policy?

Support varies by browser and by feature. Browsers ignore features they do not recognise, so including them is harmless, and the protection applies wherever support exists.

What happens if I block a feature my site needs?

The feature silently fails and the browser console shows a policy violation message. Add the feature with (self) or the right origin and reload to fix it.