What is the Permissions Policy header and how does it differ from Feature Policy?

Permissions Policy is the renamed and updated version of the Feature Policy header. It controls which browser APIs and features (camera, microphone, geolocation, payment, etc.) your website and embedded iframes can access. The main difference is the syntax: Feature Policy used a space-separated format while Permissions Policy uses a structured header format with parentheses. Modern browsers support Permissions Policy, and you should use it instead of the deprecated Feature-Policy header.

Which Permissions Policy directives should I set for a typical website?

For most websites, you should disable features you do not use. A good starting point is to set camera, microphone, geolocation, payment, and usb to () which blocks all access. If your site uses specific features, allow them only for your own origin using (self). For sites with embedded content, you can grant access to specific third-party origins. The key principle is to deny everything by default and only allow what you actually need.

How do I test if my Permissions Policy header is working correctly?

You can verify your Permissions Policy header using browser developer tools by checking the Response Headers in the Network tab. Chrome DevTools also shows policy violations in the Console when a blocked feature is accessed. Online tools like the SiteSecurityScore scanner will analyze your Permissions Policy configuration and flag any missing or misconfigured directives. You can also use the document.featurePolicy JavaScript API in the browser console to check which features are allowed.

How to Configure Permissions Policy for Your Website

What is Permissions Policy and why it matters#

Permissions Policy is an HTTP response header that gives website owners fine-grained control over which browser features and APIs can be used on their pages. It replaced the older Feature-Policy header and provides a standardized way to allow or deny access to powerful browser capabilities such as the camera, microphone, geolocation, payment processing, and many more. When a feature is restricted by the policy, any attempt to use it will silently fail, preventing both your own code and any embedded third-party content from accessing those APIs.

Most websites only need a small fraction of the features that modern browsers expose. A blog, for example, has no legitimate reason to access the user's camera or request payment credentials. Without a Permissions Policy in place, every feature remains available by default, which means that a compromised script or a malicious third-party embed could quietly request access to sensitive device APIs. By explicitly disabling the features your site does not use, you dramatically reduce your attack surface and make it much harder for bad actors to exploit your visitors.

Implementing a Permissions Policy is also a strong signal to security auditors and compliance teams that your organization takes a defense-in-depth approach to web security. It complements other security headers like Content Security Policy and Strict-Transport-Security by addressing a different layer of browser behavior. You can scan your website to check which permissions your site currently exposes and identify opportunities to tighten your policy.

Reduces attack surface by disabling unused browser features
Prevents third-party scripts and iframes from accessing sensitive device APIs
Provides transparent, enforceable declarations of feature usage intent
Supports privacy-by-design principles and regulatory compliance efforts
Works alongside CSP and HSTS for a layered defense-in-depth strategy

Available permission directives you should know#

The Permissions Policy specification defines a wide range of directives, each governing a specific browser feature or API. Understanding which directives are available helps you make informed decisions about what to allow and what to block. Directives are grouped into categories such as media capture, sensors, navigation, and display features.

Below is a summary of the most commonly used permission directives. Depending on your site's functionality, you may need to allow some of these features for your own origin while blocking them for embedded third-party content.

Key feature directives

camera Video capture device access

microphone Audio capture device access

geolocation User location tracking

fullscreen Fullscreen display mode

payment Payment Request API

autoplay Media autoplay behavior

display-capture Screen sharing and capture

usb WebUSB device access

bluetooth Web Bluetooth API

accelerometer Device motion sensor

gyroscope Device orientation sensor

magnetometer Magnetic field sensor

Each directive accepts one of three policy values that determine which origins are allowed to use the feature:

() Blocks the feature entirely for all origins, including your own site. This is the most restrictive setting and should be your default for features you do not use.
(self) Allows the feature for your own origin only. Embedded iframes and third-party scripts will be blocked from using it. This is the recommended setting for features your site needs.
(*) Allows the feature for all origins, including embedded content. Use this sparingly and only when third-party embeds genuinely need the feature.

For a deeper dive into how Permissions Policy works at the protocol level and how it interacts with iframes, see our Permissions Policy reference.

How to use the generator step by step#

Our Permissions Policy generator walks you through the process of building a complete header value without needing to memorize the syntax. It presents every available directive, lets you choose a policy for each one, and produces a ready-to-use header that you can copy straight into your server configuration. You can open the Permissions Policy generator to follow along.

Start by reviewing the list of available features in the generator. Each feature is displayed with a brief description of what it controls and a dropdown selector for the policy value. For most sites, you will want to set the majority of directives to () to block them entirely, and only enable the handful of features your site actually uses with (self). As you change each setting, the live preview panel updates in real time so you can see exactly how your header will look.

Once you are satisfied with your selections, use the copy button to grab the full header value. The generator outputs the header in the standard structured header format that all modern browsers understand. For additional details on syntax edge cases and browser compatibility, consult MDN's Permissions Policy documentation.

Here is an example of what a generated header looks like for a site that only needs geolocation and fullscreen access:

Permissions-Policy header example

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

After copying the header, add it to your web server configuration. In Apache, use the Header set directive in your .htaccess or virtual host config. In Nginx, use add_header. If you use a CDN like Cloudflare or Vercel, you can typically set custom response headers in your platform's dashboard or configuration file.

Configuration examples by site type#

Different types of websites have different feature requirements. Below are three practical examples that demonstrate how to tailor your Permissions Policy to match your site's actual needs. Use these as starting points and adjust based on the specific functionality your application provides.

Blog or marketing site

A static blog or marketing site typically does not need access to any device APIs. The safest approach is to block every feature and only enable fullscreen if you embed video content. This produces the tightest possible policy and ensures that even if a third-party analytics script is compromised, it cannot access the camera, microphone, or location.

Blog / marketing site policy

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

Video conferencing app

A video conferencing application needs camera, microphone, and display-capture access for its core functionality. You should allow these for your own origin while still blocking everything else. If you embed third-party components that also need media access, you can add their specific origins to the allowlist instead of using a wildcard.

Video conferencing app policy

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

E-commerce site

An e-commerce site needs the Payment Request API for streamlined checkout but has no reason to access motion sensors or screen capture. Enabling payment for your own origin while blocking device sensors is a strong default. If your checkout flow uses a third-party payment processor embedded in an iframe, you may need to add that processor's origin to the payment directive.

E-commerce site policy

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

Privacy benefits and compliance considerations#

Permissions Policy is one of the most practical tools available for implementing the privacy-by-design principle that underpins regulations like the GDPR, CCPA, and ePrivacy Directive. These frameworks require organizations to minimize data collection and limit processing to what is strictly necessary. By explicitly blocking browser features that your application does not need, you create a technical enforcement layer that prevents accidental or unauthorized data collection at the browser level, before any data ever reaches your servers.

One of the most significant privacy risks on the modern web comes from third-party scripts. Analytics libraries, advertising tags, social media widgets, and embedded chat tools all run with the same privileges as your own code unless you restrict them. A compromised or malicious third-party script could silently invoke the Geolocation API to track your users' physical location, activate the microphone to record audio, or use device sensors to fingerprint browsers. Permissions Policy prevents these scenarios by ensuring that features you have not explicitly allowed cannot be used by any code running on your page, regardless of its origin.

Third-party scripts can silently request permissions

Without a Permissions Policy, any JavaScript running on your page can attempt to access device APIs like the camera, microphone, or geolocation. Even if the browser prompts the user, the request itself may erode trust and create a confusing experience. A restrictive Permissions Policy ensures these requests are blocked before the browser ever shows a prompt, giving you full control over which features are available on your site.

When documenting your privacy posture for auditors or building a Record of Processing Activities under GDPR, you can point to your Permissions Policy as concrete evidence that device-level APIs are restricted. This demonstrates a proactive approach to data minimization that goes beyond server-side controls. Combined with a strong Content Security Policy and transport layer security, Permissions Policy helps you build a comprehensive security and privacy architecture. For more on building a layered header strategy, see our advanced security headers guide.

Testing and monitoring your Permissions Policy#

After deploying your Permissions Policy header, you should verify that it is being served correctly and that it does not break any legitimate functionality on your site. The easiest way to check is through your browser's developer tools. In Chrome or Edge, open DevTools, navigate to the Application tab, and look for the Permissions Policy section under the Security heading. This panel shows you exactly which features are allowed and which are blocked for the current page, along with the origin restrictions for each directive.

It is important to understand what happens when a blocked feature is requested. Unlike Content Security Policy, which can generate visible console errors and violation reports, Permissions Policy operates silently. When JavaScript attempts to use a feature that the policy blocks, the API call simply fails or returns a denied state without throwing an error. This means your application should handle these cases gracefully, for example by checking navigator.permissions.query() before attempting to use a feature.

Here are some practical tips for testing your Permissions Policy after deployment:

Open DevTools and check the Application tab to confirm the policy is active and parsed correctly
Inspect the response headers in the Network tab to verify the header value matches what you configured
Test each feature your site uses to make sure it still works after the policy is applied
Try triggering blocked features from the console to confirm they are denied as expected
Test embedded iframes and third-party widgets to ensure they cannot access restricted features
Run a full site scan periodically to catch configuration drift or changes introduced by deployments