Permissions-Policy Inspect

Diagnose security headers and policies in your browser. No input is sent to a server. Use it for first-pass checks before rollout.

Status

Runs in your browser. No input is sent to a server. Use this as a first-pass diagnostic step.

How to use

Paste Permissions-Policy and click “Parse”. It lists per-feature permissions.

Notes (this tool)

  • Accepts both Permissions-Policy: and Feature-Policy: header lines.

About this page

What does this tool do?

Parse Permissions-Policy and list per-feature permissions (camera/geolocation, etc.).

Useful for checking unexpected allow/deny settings.

Even long headers become readable, making it practical for audits and operational checks.

Permissions-Policy basics

  • Restricts allowed origins per feature.
  • () disables; (self) allows same-origin.
  • Allowed external origins are listed like "(https://example.com)".

Typical use cases

  • Limit camera/microphone in embedded iframes
  • Prevent third-party tags from accessing features
  • Check migration from Feature-Policy

Writing tips

  • List multiple origins separated by spaces.
  • Quote origins with double quotes for safety.
  • Separate features with commas across the policy.

Syntax (how to read)

The basic form is "feature=allowlist". The allowlist is parenthesized and contains self/none/origins.

  • geolocation=() → disables geolocation (allowed nowhere)
  • camera=(self) → allows camera only for same-origin
  • microphone=("https://example.com") → allows for that origin

Because interpretation can vary by browser/spec version, also verify behavior in real environments (DevTools or E2E).

What this tool does

  • Split and display policy directives
  • List self/none/origins
  • Organize per-feature permissions

Common features (examples)

Examples of feature names you often see. The baseline is to allow only what you need.

  • geolocation / camera / microphone
  • payment / fullscreen / autoplay
  • clipboard-read / clipboard-write

Common pitfalls

  • Mixing Feature-Policy and Permissions-Policy causes confusion
  • Typos in allowed origins end up denying all
  • Misreading () leads to missing allows

Security & privacy angle

Permissions-Policy is not a direct exploit mitigation, but a way to minimize risk by reducing access to powerful browser features.

  • Prevent third-party content (iframes/tags) from using unnecessary features
  • Make intended behavior explicit and easier to maintain

Suggested workflow

  • Paste current header → check for unintended allows
  • List only required features and minimize
  • Verify behavior in browsers (including iframes/third parties)

Operational notes

  • Recommended values are environment-dependent. Validate against functional requirements before applying.
  • In production, use phased rollout with report monitoring.

Referenced specs

  • Permissions Policy (W3C)
  • MDN: Permissions-Policy

FAQ

How is it different from Feature-Policy?

Permissions-Policy is the successor to Feature-Policy. Older headers may still appear.

How is it different from CSP or CORS?

CSP controls resource loading, CORS controls cross-origin reads, and Permissions-Policy controls access to powerful browser features (camera, etc.).

References

  1. Permissions Policy
  2. MDN: Permissions-Policy

These links are generated from site_map rules in recommended diagnostic order.

  1. Referrer-Policy Inspect — Parse Referrer-Policy and check referrer exposure
  2. CSP Report Analyzer — Analyze CSP report JSON and summarize violation patterns
  3. HSTS Inspect — Parse HSTS to verify HTTPS enforcement
  4. CSP Inspect — Parse and evaluate CSP directives
  5. Security Headers Audit — Audit presence of major security headers
  6. Security Headers Recommendation — Suggest recommended values for missing headers
  7. Security Headers Fix Plan — Create a prioritized header-fix plan
  8. CSP Nonce/Hash Helper — Generate and verify CSP nonce/hash values

Security Headers

Go from missing-header detection to concrete fix planning

Example

geolocation=(), camera=(self)