Permissions-Policy Header Builder
Construct enterprise-grade Permissions-Policy (Feature-Policy) HTTP security headers to lock down camera, microphone, geolocation, and privacy APIs.
Directives Matrix
cameraW3C RecommendationControls access to video input devices such as webcams and built-in mobile cameras.
microphoneW3C RecommendationControls access to audio capture hardware and built-in microphone arrays.
geolocationW3C RecommendationRestricts access to the Geolocation API for device coordinates and GPS positioning.
speaker-selectionW3C DraftGoverns audio output device selection via the Audio Output Devices API.
midiW3C RecommendationControls access to Musical Instrument Digital Interface (MIDI) software and hardware.
usbW3C DraftRestricts low-level communication with connected Universal Serial Bus (USB) peripherals.
serialW3C DraftControls interaction with physical RS-232 serial ports and microcontroller bridges.
bluetoothExperimentalRestricts scanning and pairing with nearby Bluetooth Low Energy (BLE) peripherals.
hidW3C DraftRestricts communication with uncommon gamepads, pedals, and hardware knobs.
accelerometerW3C RecommendationMonitors linear acceleration along three physical spatial dimensions.
gyroscopeW3C RecommendationMeasures rates of angular rotation along physical hardware pitch, yaw, and roll axes.
magnetometerW3C RecommendationMeasures ambient magnetic fields and orientation relative to geomagnetic poles.
ambient-light-sensorW3C DraftMonitors ambient illuminance levels measured by surrounding photodetectors.
autoplayW3C RecommendationControls whether video or audio streams can initiate audio-rich playback automatically.
clipboard-readW3C DraftRestricts asynchronous programmatic retrieval of operating system clipboard contents.
clipboard-writeW3C DraftControls programmatic copy operations to modify operating system clipboard buffers.
browsing-topicsExperimentalControls whether third-party trackers can extract browser behavioral interests.
interest-cohortExperimentalExplicitly opts out of federated interest cohort profiling across ad networks.
run-ad-auctionExperimentalGoverns execution of client-side ad bidding scripts via Protected Audience APIs.
join-ad-interest-groupExperimentalRestricts advertiser scripts from registering the user into remarketing buckets.
sync-xhrW3C RecommendationControls blocking synchronous XMLHttpRequest calls that freeze the primary browser UI thread.
screen-wake-lockW3C RecommendationGoverns whether the application can keep the device screen illuminated indefinitely.
fullscreenW3C RecommendationControls whether iframes and elements can transition into full-viewport immersion mode.
paymentW3C RecommendationControls merchant checkout integration with Apple Pay, Google Pay, and PaymentRequest.
display-captureW3C RecommendationRestricts capturing monitor visual surfaces via getDisplayMedia screen recorders.
picture-in-pictureW3C RecommendationControls whether floating desktop picture-in-picture video viewports can be spawned.
web-shareW3C RecommendationGoverns invoking native mobile sharing sheets via navigator.share().
Generated Server Output
camera=(), microphone=(), geolocation=(), speaker-selection=(), midi=(), usb=(), serial=(), bluetooth=(), hid=(), accelerometer=(), gyroscope=(), magnetometer=(), ambient-light-sensor=(), autoplay=(self), clipboard-read=(), clipboard-write=(self), browsing-topics=(), interest-cohort=(), run-ad-auction=(), join-ad-interest-group=(), sync-xhr=(), screen-wake-lock=(self), fullscreen=(self), payment=(self), display-capture=(), picture-in-picture=(self), web-share=(self)
20
7
0
For maximum visitor privacy, always ensure browsing-topics=() and interest-cohort=() are set to disallow. This prevents ad network trackers from aggregating your users into interest groups across external websites.
100% Client-Side In-Memory Execution: All header string compilations, syntax conversions, and configuration exports are calculated directly in your local browser sandbox. No domain names, origin parameters, or server infrastructure blueprints are ever transmitted to or stored on external servers.
Permissions-Policy Architecture: Granular Hardware & API Governance for Modern Web Applications
The web platform has evolved from static hypertext documents into a sophisticated operating environment capable of interfacing directly with high-definition cameras, microphone arrays, Bluetooth peripherals, USB microcontrollers, and motion sensors. While these capabilities empower web-based applications, they create significant attack vectors when third-party ad networks, social widgets, analytics trackers, or supply-chain script dependencies operate in the same execution context.
The Permissions-Policy HTTP response header provides security engineers with authoritative control over which browser features and hardware interfaces can be invoked by top-level web documents and nested <iframe> frames. By implementing the Principle of Least Privilege (PoLP) at the HTTP layer, you can prevent unauthorized eavesdropping, unauthorized geolocation triangulation, battery drainage from ambient sensors, and intrusive tracking mechanisms.
Subresource Isolation
Even if a malicious advertiser or third-party partner embeds an iframe, the browser denies access to cameras, microphones, or payment APIs if the parent policy does not explicitly delegate access.
Anti-Fingerprinting Defense
Disabling device motion sensors, magnetometers, and ambient light sensors mitigates advanced hardware fingerprinting vectors used by profiling bots to track users across incognito sessions.
Behavioral Privacy Protection
Directives like browsing-topics=() prevent advertising algorithms from silently monitoring domain visits to construct commercial behavioral profiles without express consent.
Standard RFC 8941 Structured Fields Syntax Breakdown
Permissions-Policy replaces the legacy Feature-Policy syntax with standard HTTP Structured Fields. Directives are delimited by commas, and origin parameters are wrapped in parentheses:
Comparative Matrix: Permissions-Policy vs. Feature-Policy vs. CSP sandbox
Web security engineers frequently navigate overlapping HTTP header directives. Understanding where Permissions-Policy fits relative to our Content Security Policy (CSP) header generator and legacy Feature-Policy ensures complete defensive coverage without breaking legitimate site functionality. Furthermore, when delegating high-entropy device headers to CDNs, verify your origin headers with the User-Agent client hints inspector to ensure cross-origin privacy delegations remain intact.
| Specification | Primary Defense Scope | Syntax Format | Browser Status | Header Name |
|---|---|---|---|---|
| Permissions-Policy | Hardware, APIs, and Privacy Sandbox APIs | RFC 8941 Structured Items: feature=(self) | Current W3C Standard | Permissions-Policy |
| Feature-Policy | Legacy hardware restriction | Semicolon-separated: feature 'self' | Deprecated (Obsolescent) | Feature-Policy |
| CSP: sandbox | Form submission, popups, script execution | Flag list: allow-scripts allow-forms | Active W3C Standard | Content-Security-Policy |
| Iframe allow attribute | Per-frame authorization delegation | Inline string: allow="camera; microphone" | Active HTML Standard | <iframe allow="..."> |
Deployment Guide: Server-Level Header Configurations for Production
To guarantee bulletproof protection, the Permissions-Policy header must be emitted as a true HTTP response header directly from your reverse proxy, web server, or CDN edge cache. Here is how leading infrastructure engines implement this header:
Nginx (Reverse Proxy & Ingress)
Add the directive within your primary http { }, server { }, or route location / { } block. The always parameter ensures the header is attached even during 4xx/5xx HTTP error states:
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
Apache HTTP Server (.htaccess)
Verify that mod_headers is enabled inside Apache. Place the rule inside your document root .htaccess file or virtual host configuration:
<IfModule mod_headers.c>
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>Caddy Web Server (Caddyfile)
Caddy allows straightforward declarative header definitions directly inside any domain declaration block:
header Permissions-Policy "camera=(), microphone=(), geolocation=()"
Vercel & Next.js Edge Routing
In Next.js App Router applications, declare headers inside next.config.js or define them inside root vercel.json:
// next.config.js
module.exports = {
async headers() {
return [{
source: '/:path*',
headers: [{
key: 'Permissions-Policy',
value: 'camera=(), microphone=(), geolocation=()'
}]
}];
}
};Frequently Asked Questions (FAQ)
What is the HTTP Permissions-Policy header?
The Permissions-Policy HTTP header (formerly Feature-Policy) gives web developers explicit granular control over browser features, hardware devices, and APIs available to the page and any embedded third-party iframes. It hardens security by disabling sensitive hardware such as cameras, microphones, sensors, and GPS geolocation.
What is the difference between Feature-Policy and Permissions-Policy?
Feature-Policy is the legacy syntax deprecated by the W3C Web Platform Incubator Community Group. Permissions-Policy is the modern standardized replacement utilizing Structured Fields for HTTP (RFC 8941), using parenthesized origin syntax like camera=(self) or geolocation=() instead of whitespace-separated quotes.
How does Permissions-Policy enhance website security?
By enforcing a strict Permissions-Policy, site owners block malicious scripts, third-party advertising SDKs, and compromised nested iframes from turning on microphones, accessing device coordinates, reading the OS clipboard, or executing battery-draining cryptographic coin miners.
Why should I disable the browsing-topics and interest-cohort directives?
Disabling browsing-topics=() and interest-cohort=() prevents your website users from having their cross-site behavioral histories grouped into targeted advertising profiles by automated tracking algorithms like Google's Topics API and legacy FLoC.
Can Permissions-Policy be configured in HTML <meta> tags?
No. Modern browser security models strictly mandate that Permissions-Policy be delivered via genuine HTTP response headers sent directly by the web server or reverse proxy. The browser ignores Permissions-Policy inside standard HTML meta http-equiv tags.
What is the syntax for granting feature access to a trusted third-party domain?
To authorize a specific third-party origin, wrap the directive target in parentheses and enclose the domain in double quotes, such as: payment=(self "https://payments.stripe.com"). Multiple origins can be separated by spaces within the parentheses.
Related & Complementary Utilities
Explore more privacy-first client-side web tools.
DKIM Selector Public Key Record Inspector & Generator
Inspect, generate, and validate RFC 6376 DKIM DNS TXT records with 2048-bit RSA key health diagnostics.
URL Punycode & Internationalized Domain (IDN) Converter
Convert Unicode internationalized domain names (IDNs) and URLs into ASCII Punycode (xn--) and vice-versa in real-time according to RFC 3492 and RFC 5891.
SPF Record Generator & Permissive Syntax Validator
Generate, test, and audit RFC 7208 SPF records. Detect the 10 DNS lookup limit, avoid Permerrors, and prevent unauthorized email spoofing.
WHOIS Domain Age Checker & Expiration Auditor
Query live WHOIS registries to inspect domain creation dates, total active age, registrar information, expiration milestones, and trust metrics.