Remediation guide

How to Set a Permissions-Policy Header (and Which Features to Disable)

Your site probably doesn’t need camera access, microphone access, or the ability to request the user’s location — but without a Permissions-Policy header, any script running on your page, and any iframe you embed, can ask the browser for those APIs. One compromised dependency or a third-party ad iframe is all it takes. A single header tells the browser exactly which features you’ve intentionally enabled, and blocks everything else at the browser level — before any JavaScript even runs.

• What Permissions-Policy controls
• How the allowlist syntax works
• A safe baseline policy
• Common directives explained
• Permissions-Policy and iframes
• Deploy on your platform
• Verify with HardenCheck
• FAQ

What Permissions-Policy controls

The Permissions-Policy response header (formerly Feature-Policy, renamed in 2020) is a declarative allowlist for browser APIs that carry privacy or security risk. When a browser feature appears in the policy with an empty allowlist — written () — the browser refuses any attempt to use that feature on your page, including from third-party scripts and iframes. When a feature is absent from the policy, default browser behaviour applies (which for most features means the browser’s own permission prompt still governs access).

The APIs Permissions-Policy governs are not obscure. They include:

What gets controlled	Why it matters
camera, microphone	Physical device access. A third-party script that activates these triggers no extra browser prompt if the user previously granted your origin permission.
geolocation	Precise location. Previously-granted permissions can be used by any script on the page, not just yours.
payment	The Payment Request API. Should be locked to (self) on any page that uses it; disabled everywhere else.
usb, hid, serial	Hardware API access. Rarely needed; high impact if misused.
display-capture	Screen capture via getDisplayMedia(). A tool for legitimate conferencing apps; a powerful exfiltration vector if abused.
clipboard-read	Read whatever the user has copied — passwords, 2FA codes, confidential text — without a visible prompt in some contexts.

Setting a Permissions-Policy header does not replace browser permission prompts. It is a server-side ceiling: even if the user would be willing to grant access, a feature blocked by Permissions-Policy will be denied unconditionally. This makes it effective as a defence against supply-chain attacks: a compromised npm package that calls navigator.mediaDevices.getUserMedia() will get a NotAllowedError if camera=() is set, without any user interaction required.

How the allowlist syntax works

Each directive takes an allowlist in parentheses. There are three values to know:

Syntax	Meaning
feature=()	Deny all. The feature is blocked for your origin and every iframe you embed. This is the right default for any feature you don’t use.
feature=(self)	Allow same origin only. Your pages can use the feature; third-party iframes cannot unless you explicitly grant it via the allow attribute.
feature=*	Allow all origins. Equivalent to no restriction. Only use this if you explicitly want iframes from any origin to access the feature.

You can also allow specific third-party origins by listing them:

Permissions-Policy: camera=(self "https://video.example.com")

This allows camera access on your own pages and in iframes from video.example.com, and denies it everywhere else.

Multiple directives are separated by commas:

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

A safe baseline policy

The following policy disables every high-risk browser API. It is safe to deploy on any site that does not use video calling, geolocation, hardware access, or screen capture. Check the list of directives in the next section before deploying if you’re unsure whether your site uses any of these features.

Permissions-Policy:
  camera=(),
  microphone=(),
  geolocation=(),
  payment=(),
  usb=(),
  display-capture=(),
  clipboard-read=(),
  hid=(),
  serial=()

Written as a single header line (required by most web servers):

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), display-capture=(), clipboard-read=(), hid=(), serial=()

Common directives explained

These are the directives HardenCheck evaluates and the ones most commonly flagged by security scanners:

camera and microphone

Both call navigator.mediaDevices.getUserMedia(). If your site has no video calling, no voice recording, and no QR scanner, set both to (). If you use them on specific pages (e.g., a video consultation page), set (self) and ensure only that page triggers the prompt.

geolocation

Calls navigator.geolocation.getCurrentPosition() or watchPosition(). If your site shows maps or location-based results, set (self). If it does not, set (). Most marketing and SaaS sites do not need geolocation at all.

payment

Controls the Payment Request API — the browser-native checkout flow (Apple Pay, Google Pay via the browser). This is distinct from client-side libraries like Stripe.js, which do not require this permission. Set () unless you are explicitly using the Payment Request API.

display-capture

Controls navigator.mediaDevices.getDisplayMedia() — screen sharing. Used by conferencing tools. Set () on any site that is not a video conferencing application.

clipboard-read and clipboard-write

clipboard-read covers navigator.clipboard.readText() and readClipboardItems(). This is the sensitive one: reading the clipboard can capture whatever the user last copied — a password, a 2FA code, a private document snippet. Set () unless you have a genuine use case (e.g., a password manager or rich-text editor that pastes formatted content). clipboard-write controls writeText() — writing to the clipboard. This is lower risk and commonly needed for “copy to clipboard” buttons. Set (self) if you use copy buttons.

fullscreen

Controls Element.requestFullscreen(). Unlike the other directives, the default value for fullscreen is (self) in most browsers — meaning it is already restricted to the same origin without an explicit header. Setting fullscreen=() blocks it entirely, including for your own pages. Only set it to () if your site has no full-screen video players or image viewers.

Permissions-Policy and iframes

The header sets a ceiling for your entire origin. An iframe can only access a feature if both of these are true:

1. Your site’s Permissions-Policy header allows the feature for the iframe’s origin (or uses *)
2. The <iframe> element has an allow attribute that grants the feature

This means you can set a restrictive site-wide policy while giving specific trusted iframes access. For example, if you embed a Zoom widget that needs camera access:

<!-- Site-wide header: Permissions-Policy: camera=("https://zoom.us") -->
<iframe src="https://zoom.us/wc/12345/join"
        allow="camera; microphone"></iframe>

The allow attribute on the iframe is a request; the header on the parent page is the grant. If the header doesn’t allow the feature for that origin, the allow attribute is ignored.

Deploy it on your platform

nginx

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

Apache (.htaccess)

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

Vercel (vercel.json)

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        {
          "key": "Permissions-Policy",
          "value": "camera=(), microphone=(), geolocation=(), payment=(), usb=(), display-capture=(), clipboard-read=()"
        }
      ]
    }
  ]
}

Next.js (next.config.js)

const securityHeaders = [
  {
    key: 'Permissions-Policy',
    value: 'camera=(), microphone=(), geolocation=(), payment=(), usb=(), display-capture=(), clipboard-read=()'
  }
];

module.exports = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: securityHeaders,
      },
    ];
  },
};

Netlify (_headers file)

/*
  Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), display-capture=(), clipboard-read=()

Cloudflare Pages (_headers file)

/*
  Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), display-capture=(), clipboard-read=()

Express.js

app.use((req, res, next) => {
  res.setHeader(
    'Permissions-Policy',
    'camera=(), microphone=(), geolocation=(), payment=(), usb=(), display-capture=(), clipboard-read=()'
  );
  next();
});

If you use the Helmet middleware, it does not set Permissions-Policy by default. Add it with the permissionsPolicy option (available in Helmet 7+):

app.use(helmet({
  permissionsPolicy: {
    policy: {
      camera: [],
      microphone: [],
      geolocation: [],
      payment: [],
      usb: [],
      'display-capture': [],
      'clipboard-read': []
    }
  }
}));

An empty array ([]) in Helmet’s API maps to () in the header value — deny all.

Verify with HardenCheck

After deploying your Permissions-Policy header, paste your raw response headers into HardenCheck. It checks whether the header is present, whether the syntax is valid structured-fields format (the new feature=() syntax, not the deprecated feature 'none' syntax), and whether the high-risk features — camera, microphone, geolocation — are restricted. You can test different policy values by editing the paste directly; the grade updates immediately.

Grade my headers with HardenCheck →

Frequently asked questions

Also in the Copper Bay Labs ship-safety suite

Permissions-Policy is one of several security headers HardenCheck checks — here are guides for the others: