MCP Server Permissions Policy Security: Permissions-Policy header, feature gating, iframe allow= attribute, sandbox vs Permissions-Policy, and Feature-Policy v1 vs v2

What Permissions-Policy actually controls

When a browser renders a document, it builds a "feature policy set" that determines which powerful browser APIs are available to that document and to every <iframe> embedded within it. The Permissions-Policy header, sent by the server alongside the HTML response, is the primary mechanism for configuring that set.

The header syntax is a structured field: a comma-separated list of feature names, each followed by a parenthesized allowlist. An empty allowlist — () — means "no origin may use this feature." A value of (self) means only the same-origin document may use it. A value of * means any origin may use it (including cross-origin iframes). Examples:

# Deny all device APIs — strongest hardening posture
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(),
  usb=(), hid=(), serial=(), bluetooth=(), screen-wake-lock=(),
  compute-pressure=(), ambient-light-sensor=(), accelerometer=(),
  gyroscope=(), magnetometer=()

# Allow geolocation for same-origin but deny camera/mic entirely
Permissions-Policy: geolocation=(self), camera=(), microphone=()

# Allow payment for same-origin and a known payment iframe origin
Permissions-Policy: payment=(self "https://pay.stripe.com")

Features not mentioned in the header default to the browser's built-in default, which varies per feature. Most powerful APIs default to (self) — allowed for the top-level document, denied for cross-origin iframes. Some features like ambient-light-sensor default to () already. The practical implication is that omitting Permissions-Policy is not the same as denying everything: the defaults leave several APIs available to the top-level document.

The fourteen APIs you should deny by default

SkillAudit audits for these features on every MCP server and client deployment:

For an MCP server that serves no device-oriented features (the vast majority), a single header line covers all fourteen:

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(),
  usb=(), hid=(), serial=(), bluetooth=(), screen-wake-lock=(),
  compute-pressure=(), ambient-light-sensor=(), accelerometer=(),
  gyroscope=(), magnetometer=()

sandbox vs Permissions-Policy — two orthogonal mechanisms

Developers frequently confuse the HTML sandbox attribute on <iframe> with Permissions-Policy. They are orthogonal controls that restrict different things:

A correct setup for an MCP client that renders tool output in a sandboxed iframe looks like this:

<!-- Sandbox: scripts allowed (to render interactive tool output),
     forms blocked, popups blocked, navigation blocked,
     but same-origin access allowed so postMessage can work -->
<iframe
  src="/tool-output-renderer"
  sandbox="allow-scripts allow-same-origin"
  allow="camera 'none'; microphone 'none'; geolocation 'none'; payment 'none'"
></iframe>

The allow= attribute uses a semicolon-separated list of feature-origin pairs and restricts the iframe further — but it can only restrict relative to what the parent document's Permissions-Policy allows. If the parent HTTP header already says camera=(), the iframe cannot use the camera regardless of whether the allow= attribute specifies it. The allow= attribute is an additional restriction layer, not an expansion mechanism.

Cross-origin iframe tool output rendering

Some MCP client architectures render tool output in a cross-origin iframe — a sandboxed origin like sandbox.skillaudit.dev serves as the rendering context. This is a stronger security boundary than same-origin sandboxing because the iframe's browsing context is in a separate origin, meaning XSS inside the iframe cannot reach the parent document's cookies, DOM, or storage. However, cross-origin iframes have their own Permissions-Policy configuration from their own HTTP response headers.

This creates a two-layer policy system:

1. Parent document header: Sets the feature availability ceiling for the iframe. If the parent says camera=(), the iframe cannot use the camera regardless of its own header.
2. iframe's HTTP header: The cross-origin server serving the iframe's content sends its own Permissions-Policy header. This applies to the iframe's document.
3. Parent's allow= attribute: Further restricts the intersection of the above two.

The effective policy for a feature in an iframe is the intersection of: (a) the parent's Permissions-Policy allows it for the iframe's origin, (b) the parent's allow= attribute allows it, and (c) the iframe's own server sends a Permissions-Policy that allows it. All three must permit the feature for it to be available inside the iframe.

Feature-Policy v1 vs Permissions-Policy v2

The header was originally named Feature-Policy when it shipped in Chrome 60. The W3C Permissions Policy specification renamed it to Permissions-Policy in 2020, changed the syntax from HTTP header field list to structured field dictionary, and revised how default allowlists work. The two versions are not equivalent and browsers that support the new header ignore the old one.

Interaction with the Permissions API

The browser's Permissions API (navigator.permissions.query()) allows JavaScript to check whether a feature is currently granted, denied, or prompt-pending — without triggering the actual permission prompt. A Permissions-Policy that denies a feature causes navigator.permissions.query({name: 'camera'}) to return state 'denied', just as if the user had previously denied the permission in their browser settings. This prevents JavaScript from distinguishing between "user denied" and "policy denied" — both return the same state, and neither allows access.

This interplay matters for MCP server audit work: an audit that checks navigator.permissions.query() will correctly report 'denied' for features blocked by Permissions-Policy, giving false confidence that the user explicitly denied access. SkillAudit's probe suite tests Permissions-Policy enforcement directly at the API call level, not via navigator.permissions, to avoid this ambiguity.

Caddy and nginx configuration

Setting the header in Caddy (the factory's default server):

# Caddyfile
skillaudit.dev {
  header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), hid=(), serial=(), bluetooth=(), screen-wake-lock=(), compute-pressure=(), ambient-light-sensor=(), accelerometer=(), gyroscope=(), magnetometer=()"
  file_server {
    root /srv/product
  }
}

In nginx:

add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), hid=(), serial=(), bluetooth=(), screen-wake-lock=(), compute-pressure=(), ambient-light-sensor=(), accelerometer=(), gyroscope=(), magnetometer=()" always;

The always flag in nginx is critical: without it, the header is only sent on 2xx responses. On 4xx and 5xx responses — which might also render HTML in an error page — the header is omitted, leaving error pages unprotected.

Verifying your Permissions-Policy header

Three verification approaches, in order of reliability:

1. Browser DevTools: Open the Network tab, load the page, click the HTML document request, check the Response Headers section for Permissions-Policy. Then open the Console tab and try calling the gated API — a policy-denied API call should immediately throw NotAllowedError.
2. curl: curl -sI https://skillaudit.dev/ | grep -i permissions-policy — this checks what the server sends without any browser processing.
3. SecurityHeaders.com / Observatory: Third-party scanners check for the header and its completeness. They flag missing features and detect legacy Feature-Policy headers.

Permissions-Policy and Content Security Policy interaction

Permissions-Policy and CSP are complementary but non-overlapping controls:

• CSP controls what code can run (script-src), what resources can load (img-src, connect-src), and what iframes can be embedded (frame-src, frame-ancestors). CSP operates at the resource-loading and execution layer.
• Permissions-Policy controls which browser APIs the running code can call. Code that CSP allows to execute is still subject to Permissions-Policy on every API call.

Together, CSP restricts what code reaches the CPU and Permissions-Policy restricts what that code can do at the OS/hardware interface. For MCP servers rendering tool output, both are needed: CSP to limit where scripts can load from, Permissions-Policy to cap what those scripts can access even if they bypass CSP via inline injection.

SkillAudit findings for Permissions-Policy

Implementation checklist

• Send Permissions-Policy header (not Feature-Policy) on all HTTP responses including 4xx/5xx
• Deny camera, microphone, geolocation, payment, USB, HID, serial, Bluetooth by default
• Deny motion/sensor APIs: screen-wake-lock, compute-pressure, ambient-light-sensor, accelerometer, gyroscope, magnetometer
• Set explicit allow= attributes on all <iframe> elements rendering tool output
• Verify the header is sent on error pages (nginx: add always flag)
• Test API denial by attempting navigator.mediaDevices.getUserMedia() in console — should throw immediately
• Check cross-origin iframes also send their own restrictive Permissions-Policy headers
• Remove any remaining legacy Feature-Policy headers

Run a SkillAudit scan to check your MCP server or Claude skill's Permissions-Policy configuration. The scanner verifies both the HTTP header and the allow= attributes on any iframes used for tool output rendering, and flags legacy Feature-Policy headers that provide false security confidence.