Permissions Policy Checker — How Website Feature Controls Protect Users and Data
Web browsers have accumulated extraordinary power over the past decade. APIs that let websites access device cameras, microphones, geographic location, USB ports, Bluetooth devices, clipboard contents, payment systems, and biometric sensors have transformed what a webpage can do. But this power comes with substantial privacy and security risk — and the Permissions-Policy header is the HTTP mechanism that gives website operators explicit control over which of these powerful capabilities their pages and embedded iframes are permitted to use. A dedicated permissions policy checker tool tells you whether that control is actually in place and configured correctly.
Without Permissions-Policy, every browser API that a user's browser supports is potentially available to every script running on a page — including third-party analytics code, advertising scripts, social sharing widgets, and any other JavaScript loaded from external origins. A compromised third-party script could attempt to activate the camera silently, request location data, or read clipboard contents, all within the permissions that the user granted to the site. The free online feature policy test that our tool provides makes this risk visible by showing exactly which capabilities are and aren't restricted on any given website.
What Is the Permissions-Policy Header and How Does It Work?
Permissions-Policy is a W3C Proposed Recommendation that replaced the deprecated Feature-Policy header. It uses a structured field format where each feature directive consists of a feature name followed by an allowlist in parentheses. For example, camera=() completely disables camera access for the document and all nested contexts, while camera=(self) permits same-origin access, and camera=(self "https://trusted-partner.com") permits access for same-origin and one specific cross-origin destination.
The parenthetical allowlist format is the key difference from the old Feature-Policy syntax, which used space-separated keywords like camera 'none'; microphone 'none'. When you check website device permissions using our analyzer, it correctly parses both formats and handles comma-separated multiple directives in the Permissions-Policy structure. A permissions policy validator tool free of charge removes the need to read the specification directly — the parsed output immediately shows what each directive permits.
How Does Permissions-Policy Control Browser API Access?
When a browser receives a Permissions-Policy header, it processes the allowlist for each directive and stores the policy for that navigation context. When a JavaScript API attempts to access a feature — navigator.getUserMedia() for camera/microphone, navigator.geolocation.getCurrentPosition() for location, navigator.usb.requestDevice() for USB — the browser checks the active Permissions-Policy. If the requesting origin isn't in the allowlist for that feature, the API call fails with a DOMException or returns a denied PermissionStatus, regardless of whether the user previously granted permission.
This creates a two-factor permission model: the user must grant permission AND the site must allow the feature via Permissions-Policy. A site can therefore provide a meaningful security guarantee — "even if a user accidentally grants camera access to our site, we've disabled it in Permissions-Policy so no code running on our pages can actually activate it." When you analyze browser API controls online, this layered model becomes the foundation of a robust security argument that compliance teams and penetration testers evaluate.
What Categories of Features Does Permissions-Policy Cover?
Our free security header check for features analyzes over 30 distinct feature directives organized across nine categories. Hardware features include camera, microphone, USB, Bluetooth, MIDI, HID (Human Interface Devices), and serial port access — all direct channels to physical hardware that should be restricted on sites that don't legitimately need them. Sensor features cover the accelerometer, gyroscope, magnetometer, and ambient light sensor — APIs that enable device fingerprinting and physical world awareness that most web applications never need.
Location features center on the geolocation API, which reveals the user's physical position — highly sensitive data under virtually every privacy regulation in force. Privacy-impacting features include clipboard read access (which can silently exfiltrate copied passwords and authentication tokens), local font enumeration (which enables browser fingerprinting by revealing installed fonts), and the interest-cohort directive (which controlled the now-deprecated FLoC tracking system). When you test website camera microphone access configuration, these categories provide context for why each restriction matters.
Display features control fullscreen mode, picture-in-picture, and display capture (screen sharing). Finance features govern the Payment Request API, which integrates native payment UIs. Identity features control the Federated Credential Management API used for social login flows. Security features restrict document.domain mutation (a historical source of same-origin policy bypasses) and cross-origin isolation state. XR features control WebXR spatial tracking used by augmented and virtual reality applications. Each category represents a distinct privacy or security concern addressed by the permissions policy analyzer free tool.
Why Does Verifying Permissions-Policy Matter for Security Audits?
Security-conscious organizations conducting internal or external audits of their web properties need systematic confirmation that their Permissions-Policy configuration matches their intent. The gap between what developers believe the configuration does and what it actually does in production is surprisingly common. Server configuration changes during deployments, CDN caching behavior, A/B testing infrastructure, and feature flag systems can all inadvertently suppress or override security headers. A free web API restriction checker that operates server-side — fetching the actual headers browsers receive, not what developers believe is configured — closes this verification gap.
Compliance frameworks increasingly reference Permissions-Policy. OWASP's Security Headers project rates it as recommended. PCI DSS v4.0 guidance for web-facing applications specifically discusses controlling browser API access. The UK's NCSC, Germany's BSI, and France's ANSSI all reference Permissions-Policy in their web application security guidance. When you check hardware access policy online for an organization subject to any of these frameworks, having documented evidence of correct Permissions-Policy configuration becomes audit evidence.
How Do Wildcards Create Security Risks in Permissions-Policy?
The wildcard * in a Permissions-Policy allowlist permits any origin to use the feature — essentially disabling the restriction. This pattern is often added by developers trying to quickly resolve issues with embedded third-party content that requires certain browser APIs, but it defeats the entire purpose of the header. Our verify security permissions headers free tool specifically flags wildcard allowlists on critical features like camera, microphone, geolocation, and payment as critical security issues requiring immediate attention.
Even self alone in a cross-origin embedding context requires careful evaluation. If your site embeds iframes from partner domains that receive delegated permission through allow attributes, and your Permissions-Policy permits self for a feature like clipboard-read, scripts in the main document can read clipboard contents. Understanding this hierarchy is what distinguishes superficial online browser capabilities test tools from comprehensive analyzers that parse allowlist semantics at the per-directive level.
How Does Permissions-Policy Differ from Feature-Policy?
The website privacy access policy tool capability must handle both headers because many websites still serve Feature-Policy headers — either because they were configured before Permissions-Policy was finalized and never updated, or because they're using server frameworks that haven't adopted the new header name yet. Feature-Policy used a semicolon-separated, space-delimited syntax: camera 'none'; microphone 'none'; geolocation 'self'. Permissions-Policy uses a structured field syntax with parenthetical allowlists: camera=(), microphone=(), geolocation=(self).
Browsers handle both, but they're processed differently. Most modern browsers deprecated Feature-Policy and may not consistently enforce it, while Permissions-Policy has full support across Chrome, Firefox, Safari, and Edge. Sending both headers during a transition period was common practice, but serving Feature-Policy alone today provides unreliable protection. Our tool reports both headers when present, identifies which is in use, and notes the legacy status of Feature-Policy to inform update prioritization. A free feature control debugger online that conflates these two headers would give incorrect security assessments.
How Should You Configure Permissions-Policy for Common Website Types?
The optimal Permissions-Policy configuration depends fundamentally on what browser APIs your website actually uses. Applying a maximally restrictive policy that blocks features the site legitimately needs creates a broken user experience without providing security benefit. The correct approach — and what security auditors expect — is an allowlist of what you actually need, with everything else blocked by omission or explicit empty allowlist.
For a standard marketing website or blog that uses no hardware APIs, the recommended configuration disables camera, microphone, geolocation, payment, USB, Bluetooth, and other hardware features completely: camera=(), microphone=(), geolocation=(), usb=(), bluetooth=(), payment=(), display-capture=(), serial=(), hid=(), clipboard-read=(), interest-cohort=(). When you test cross-origin feature restriction on sites with this configuration, no third-party script, embedded iframe, or injected code can activate these hardware channels regardless of what permissions users may have previously granted.
For a video conferencing application that needs camera and microphone, the policy would permit those while restricting everything else: camera=(self), microphone=(self), geolocation=(), payment=(), usb=(), display-capture=(self). The (self) allowlist ensures only same-origin code can activate the camera — third-party analytics scripts embedded on the conference dashboard cannot initiate camera access even if they try. Checking the configuration with a browser API security scanner online after deployment confirms the intended restrictions are being enforced.
What Are the Most Important Features to Restrict?
When you check geolocation permission configuration on a website that has no location-aware functionality, finding it unrestricted suggests either misconfiguration or insufficient security hardening. The same applies to camera and microphone — two of the most privacy-invasive browser APIs whose unrestricted availability enables potential silent surveillance if scripts are compromised. Payment API access deserves restriction on all non-commerce sites because payment UI activation represents a financial attack vector.
USB and Serial API access are critical to restrict for most websites because these APIs allow JavaScript to communicate directly with physical devices — a capability that could enable data exfiltration from connected storage devices or programming of microcontrollers. Clipboard-read is increasingly targeted by malicious scripts because users frequently copy passwords, authentication codes, and sensitive data to clipboard. The check client-side feature access analysis in our tool prioritizes these high-risk features prominently in its issue reporting.
How Does Permissions-Policy Affect Embedded Iframes?
One of the most powerful and least understood aspects of Permissions-Policy is its iframe delegation model. A feature restricted in the parent document cannot be delegated to an iframe — the parent policy creates a ceiling that iframe allow attributes cannot exceed. However, even features that the parent document permits are not automatically available to iframes — each iframe must explicitly receive delegation through its allow attribute.
This creates a formal permission chain: browser → OS user permission → Permissions-Policy header → iframe allow attribute → JavaScript API call. Breaking any link in this chain denies access. When you inspect website hardware permissions on a site that embeds advertising iframes, understanding that those iframes cannot access geolocation unless both the Permissions-Policy header permits it AND the iframe tag includes allow="geolocation" is a significant privacy assurance. Our free feature policy lookup tool helps administrators verify the top-level policy that governs all embedded content on their pages.
How to Build a Permissions-Policy Header Generator Workflow
The most effective approach to Permissions-Policy implementation combines three phases. First, audit the site's actual browser API usage through code review, browser DevTools monitoring of permission requests during user sessions, and documentation review. Second, draft a Permissions-Policy header that permits exactly the APIs legitimately needed. Third, verify the implemented header matches the draft using our free website security headers validator tool against the live site.
Many teams use our Raw Parser tab to prototype policy strings during the drafting phase — pasting draft values and seeing the parsed directive breakdown with issue flags before deploying to a server. This is particularly valuable for validating that wildcard values have been removed, that critical features are explicitly restricted, and that the overall syntax is correctly formatted. After deployment, the URL checker confirms the server is actually serving the header with the expected value. For multi-site environments, the Batch Check tab enables simultaneous verification across all domains and subdomains in a single operation, with CSV export for inclusion in security reports. Regular re-verification using this test mobile feature restrictions online workflow catches regressions introduced by infrastructure changes, theme updates, or server configuration modifications before they become audit findings.