What is the Permissions Policy?

Technical Deep Dive & Specifications

The Historical Shift: From Feature Policy to Permissions Policy

In 2018, the W3C introduced Feature Policy (Feature-Policy: camera 'none'; microphone 'none'). While it solved the fundamental ambient privilege problem, its syntax had critical limitations:

1. It used a custom, bespoke whitespace-and-semicolon delimited grammar that was inconsistent with other HTTP standards.
2. It lacked integration with the emerging IETF Structured Field Values for HTTP specification (RFC 8941 / RFC 9651).
3. Directives lacked standard types (lists, booleans, tokens), making algorithmic parsing and extensibility difficult for browser implementers.

In 2020, the W3C superseded Feature Policy with the Permissions Policy specification. While legacy browsers still accept the older Feature-Policy header for backward compatibility, modern engines (Chromium 88+, Firefox 74+, Safari 15.4+) prioritize the Permissions-Policy HTTP header and the corresponding allow attribute on <iframe> elements.

The Defense-in-Depth Principle of Least Privilege

The Principle of Least Privilege (PoLP) dictates that every module, script, and execution context must be granted only the minimum capabilities necessary to perform its legitimate function.

In modern web development, websites import dozens of dependencies:

• Real-time customer support chat widgets
• Tag managers and marketing pixels (Meta Pixel, Google Tag Manager)
• Performance monitoring agents (Datadog, New Relic, Sentry)
• Payment processing gateways (Stripe, Adyen, PayPal)
• Content delivery networks (CDNs) and external font providers

If any one of these third parties suffers a supply-chain compromise (such as the British Airways Magecart attack or the Polyfill.io supply chain poisoning), an attacker running arbitrary JavaScript in your origin could attempt to:

1. Turn on the client's microphone or webcam to harvest confidential conversations or visual data.
2. Intercept GPS coordinates via navigator.geolocation to track user locations.
3. Access device motion sensors (accelerometer, gyroscope) to infer cryptographic PIN entry and keystrokes via side-channel vibration analysis.
4. Trigger silent background Web Payment requests or Web Bluetooth / Web USB connections.

By declaring an explicit Permissions-Policy header at the top-level origin, you establish a hardware sandbox that runtime JavaScript cannot bypass.

Browser Engine Architecture & Enforcement Mechanics

When the browser rendering engine (such as Chromium's Blink, WebKit, or Gecko) receives an HTTP response containing a Permissions-Policy header, it constructs an in-memory Permissions Policy Container bound to the document's Document object:

[ HTTP Response Headers ] ===> [ HTTP Parser ] 
                                     |
                                     v
                       [ Permissions Policy Parser ]
                                     |
                                     v
                        [ Document Policy Manager ]
                        +-------------------------------+
                        | feature: 'camera'      -> []  | (Disabled)
                        | feature: 'microphone'  -> []  | (Disabled)
                        | feature: 'fullscreen'  -> [*] | (All Origins)
                        +-------------------------------+
                                     |
            +------------------------+------------------------+
            |                                                 |
            v                                                 v
[ API Call: navigator.mediaDevices.getUserMedia() ]   [ <iframe> Context Creation ]
            |                                                 |
            v                                                 v
  [ Policy Check: Is 'camera' Allowed? ]              [ Policy Inheritance Check ]
            |                                                 |
      +-----+-----+                                     +-----+-----+
      |           |                                     |           |
    YES          NO                                   ALLOW       BLOCK
      |           |                                     |           |
      v           v                                     v           v
Prompt User   Reject with                        Inherit Feature  Disable Feature
Permission   SecurityError                         to Subframe      in Subframe

When a script calls navigator.mediaDevices.getUserMedia():

1. The browser engine checks the Document Policy Manager before even asking the user for hardware permission or displaying a permission prompt.
2. If the feature is disabled by policy (e.g., camera=()), the browser immediately rejects the Promise with a DOMException named NotAllowedError or SecurityError.
3. The user is never prompted, avoiding confusing permission popups and eliminating side-channel leakage.

💻 Interactive Code Playground

Starter Code

Save the following file as index.html. It demonstrates how JavaScript detects and queries the active Permissions Policy using the standardized document.permissionsPolicy API.

Line-by-Line Code Breakdown

• Lines 93–96: Shows the mock HTTP response header Permissions-Policy: camera=(), microphone=(), geolocation=(self), payment=* demonstrating RFC 8941 syntax.
• Lines 144–154: Checks for the existence of document.permissionsPolicy.allowsFeature(feature). This is the standardized JavaScript reflection API allowing client scripts to query if a feature is enabled before triggering permission prompts.
• Lines 169–182: Implements a camera test via navigator.mediaDevices.getUserMedia(). When camera=() is set by the server, this call immediately throws a NotAllowedError without opening a user dialog.
• Lines 184–198: Tests Geolocation. If restricted or unpermitted by origin, the error callback receives a standard error object indicating access denial.

Expected Browser Render Output

🛡️ Permissions Policy Runtime Inspector
-------------------------------------------------------------------------
Active Feature Governance:
[ camera          ] [ BLOCKED BY POLICY ]
[ microphone      ] [ BLOCKED BY POLICY ]
[ geolocation     ] [ ALLOWED           ]
[ payment         ] [ ALLOWED           ]
[ fullscreen      ] [ ALLOWED           ]
[ display-capture ] [ BLOCKED BY POLICY ]
-------------------------------------------------------------------------
Hardware Invocation Test Console:
[10:14:02] Attempting navigator.mediaDevices.getUserMedia({ video: true })...
[10:14:02] REJECTED: NotAllowedError - Failed to execute 'getUserMedia' on 'MediaDevices': Access to the feature "camera" is disallowed by permissions policy.