Skip to content
Aback Tools Logo

Permissions-Policy Checker

Analyse any Permissions-Policy header against a comprehensive database of 35+ browser API features. Paste your policy, click check, and instantly see which APIs are allowed, blocked, or restricted - all processed locally in your browser, no data uploaded.

Permissions-Policy Checker

Paste a Permissions-Policy (formerly Feature-Policy) header value to analyse which browser APIs are allowed, blocked, or restricted to specific origins.

Examples:

Paste a Permissions-Policy header above or load an example to get started

All analysis happens locally in your browser - no data leaves your device

Why Use Our Permissions-Policy Checker?

Instant Policy Analysis

Paste any Permissions-Policy header and get an immediate analysis of every browser API feature. The checker parses the policy, identifies each directive, and shows whether features are allowed, blocked, or restricted - no signup or page reload required.

Wildcard & Security Detection

Automatically flags features using the wildcard (*) allowlist that grants access from any origin, and highlights blocked features. Each feature is categorized by type (sensors, media, input, security, network, storage, device) with clear status badges.

Comprehensive Feature Reference

Covers 35+ standard browser API features including geolocation, camera, microphone, fullscreen, payment, WebUSB, WebBluetooth, sensors, clipboard, and emerging APIs. Unknown or experimental features are listed separately for full transparency.

Privacy-First Processing

All policy analysis happens entirely in your browser using client-side JavaScript. Your Permissions-Policy headers never leave your device - no server uploads, no cookies, no tracking. Completely free with no signup required.

Common Use Cases for Permissions-Policy Checker

Web Security Audit

Audit your Permissions-Policy header before deploying to production. Check that powerful browser APIs like geolocation, camera, and microphone are restricted to trusted origins and that no sensitive features are accidentally exposed to third-party iframes.

DevOps & Deployment Pipeline

Integrate Permissions-Policy checking into your CI/CD pipeline. Before deploying a new policy header to production, validate it through the tool to catch misconfigurations that could either break embedded features or leave security gaps in your web application.

Third-Party Integration Review

When embedding third-party content (payment iframes, social widgets, analytics), use the checker to verify that your Permissions-Policy grants only the minimum necessary permissions. Ensure third-party code cannot access sensitive APIs beyond what is required.

Feature Policy Migration

Migrating from the legacy Feature-Policy header to the modern Permissions-Policy? The checker helps you validate that the new syntax is correct and that all your feature restrictions are preserved during the transition between header formats.

Debugging Permission Errors

When a browser API fails with a NotAllowedError or SecurityError, use the checker to determine if your Permissions-Policy header is blocking it. Verify that the required feature is not in the blocked list and that the allowlist includes the correct origins.

Learning & Documentation

Learn how the Permissions-Policy header works by experimenting with different configurations. See how features are categorized, how allowlists control origin access, and how wildcard, self, and specific origins differ in their security implications.

Understanding Permissions-Policy

What is Permissions-Policy?

Permissions-Policy (formerly known as Feature-Policy) is an HTTP header that allows website owners to control which browser APIs and features can be used by their pages and embedded third-party content. It acts as a permissions gatekeeper - you can selectively enable, disable, or restrict access to powerful APIs like geolocation, camera, microphone, fullscreen, payment, and sensors. By setting a Permissions-Policy header, you create a security boundary that prevents malicious or unexpected code from accessing sensitive device capabilities without explicit permission.

How Our Permissions-Policy Checker Works

  1. Parse: The checker parses your Permissions-Policy header string into individual feature directives, correctly handling commas, parentheses, and allowlist values including self, *, and specific origins.
  2. Analyze: Each directive is matched against a comprehensive database of 35+ known browser API features. Features are categorized by type (sensors, media, input, security, network, storage, device) with clear status badges indicating whether they are blocked, restricted to specific origins, or fully open.
  3. Report: A detailed analysis is presented showing the status of every known feature, any unknown or experimental features found, security assessments for blocked and wildcard policies, and the complete policy summary statistics.

Permissions-Policy Syntax & Allowlist Values

  • Blocked (): An empty parentheses pair means the feature is blocked for all origins. The browser will deny access to the API, and any attempt to use it will throw a NotAllowedError.
  • Self: Using self inside the parentheses restricts the feature to the same origin as the page. This is the recommended setting for most features.
  • Specific Origins: You can list specific origins like "https://trusted.example.com" to allow access only from trusted domains.
  • Wildcard (*): Using * allows the feature from any origin, including all third-party iframes. Use with caution as this provides no access control.

Privacy & Security

Your Permissions-Policy headers never leave your device. All parsing, analysis, and reporting happens entirely in your browser using client-side JavaScript. No data is uploaded to any server, no cookies or tracking are involved, and no API keys or signup are required. This means you can safely analyse even the most sensitive security policies for internal applications without any privacy concerns. The tool is completely free to use with no limitations on how many policies you can check.

Frequently Asked Questions About Permissions-Policy Checker

Permissions-Policy (formerly Feature-Policy) is an HTTP header that allows website owners to control which browser APIs and features can be used by their pages and embedded third-party content. It acts as a security boundary - you can selectively enable, disable, or restrict access to powerful APIs like geolocation, camera, microphone, fullscreen, and sensors by specifying an allowlist of origins for each feature.

Permissions-Policy headers can be added at the web server level (Apache, Nginx, IIS), through your hosting platform (Cloudflare, Vercel, Netlify), or within your application code (Next.js middleware, Express.js, Django middleware). The header name is "Permissions-Policy" and the value is a comma-separated list of feature directives like "geolocation=(self), camera=(), microphone=*".

Permissions-Policy is the modern replacement for the older Feature-Policy header. The main differences are: Permissions-Policy uses a different syntax with parentheses and commas, while Feature-Policy used semicolons and no parentheses. Permissions-Policy also has a stricter default behaviour - if a feature is not listed in the policy, it is treated as if it were blocked. Most modern browsers now support Permissions-Policy, and Feature-Policy is being deprecated.

Using the wildcard (*) in a Permissions-Policy allowlist means the feature is granted to all origins, including any third-party iframes embedded in the page. This effectively disables the permission control for that feature. For example, "geolocation=*" allows any embedded iframe to access the user's location without additional checks. It is recommended to use "self" or specific origins instead of wildcards whenever possible to maintain proper access control.

Permissions-Policy acts as a gatekeeper that can block access to APIs before the Permissions API is even consulted. If a feature is blocked by Permissions-Policy (empty allowlist), the browser will deny access immediately and throw a NotAllowedError - the user will never see a permission prompt. If the policy allows the feature (self or specific origins), the normal Permissions API flow applies, and the user may be prompted to grant or deny access. Think of Permissions-Policy as a server-side access control and the Permissions API as a client-side user consent mechanism.

If you don't set a Permissions-Policy header, the browser applies its default behaviour for each feature. In modern browsers, most powerful APIs default to "self" - meaning they are allowed for the same origin but blocked for cross-origin iframes. However, some features may have different defaults depending on the browser. Setting an explicit Permissions-Policy header ensures consistent behaviour across browsers and provides defence-in-depth security against unexpected API access.

To allow a feature for a specific iframe, you need both a Permissions-Policy header that includes the origin and an "allow" attribute on the iframe element. For example, set "geolocation=(self "https://maps.example.com")" in the header and add allow="geolocation" to the <iframe> tag. The allow attribute on the iframe is required in addition to the header - without it, the header alone may not grant access to embedded content.

Yes, the Permissions-Policy Checker is completely free to use. All parsing and analysis happens entirely in your browser - no data is uploaded to any server, no API keys are required, and no signup is needed. You can check as many policies as you want, including sensitive internal policies, with complete privacy guaranteed.