DNS Tools
BROWSER FEATURES

Permissions Policy Checker

Check which powerful browser features your pages and embedded frames are allowed to use, and spot permissions open to any origin.

Run Permissions policy

The domain (or a subdomain). The check stays within that name and its www counterpart, like the full assessment.

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What Permissions-Policy does

Browsers expose powerful features to web pages: camera, microphone, geolocation, payment, USB, screen capture and more. Permissions-Policy is a response header that lets a site declare which of these its pages, and the third-party frames they embed, may use. Setting it narrows what a compromised page or an embedded third party can request. A site that never needs the camera can disable it for itself and for every frame, which makes an unexpected prompt from embedded content impossible.

It replaces the earlier Feature-Policy header, which current browsers have superseded.

How to read the result

The tool parses each feature with its allow list and shows a table.

  • feature=(): disabled for everyone, including your own page and every frame.
  • feature=(self): allowed for your own origin only.
  • feature=(self "https://partner.example.com"): allowed for your origin and a named origin.
  • Wildcard (feature=*): allowed for any origin, so embedded third parties may request it. The tool flags this for sensitive features.
  • No header: informational, since the header is optional hardening; browser defaults apply.
  • Feature-Policy only: the superseded header, which current browsers do not read; replace it.

Which features deserve attention

The tool pays particular attention to camera, microphone, geolocation, payment, USB, display capture, serial, Bluetooth and HID. Disabling those you do not use is a low-cost way to reduce what hostile or buggy embedded code can ask for. If your site does use a feature, for example geolocation for a store locator, allow it for self and only the specific embedded origins that need it.

Delegation to frames

Permissions-Policy interacts with the allow attribute of iframes. A feature must be permitted by the header for the page and then delegated by the iframe attribute to a frame; if the header disables a feature, no attribute can re-enable it. This is why a header-level restriction is a reliable ceiling: even if a page later gains an iframe from an untrusted source, the ceiling still applies. The reverse is also true, so a widget that stops working after you add a header usually points at a feature you disabled without realising a frame needed it.

Common problems

  • Wildcard allow-lists copied from examples, which permit every frame.
  • Old syntax: a header written in the Feature-Policy style does nothing under Permissions-Policy.
  • Syntax errors: commas and quoting differ from Feature-Policy; browsers ignore malformed entries.
  • Blocking a feature a widget needs: video calls, maps or payment forms stop working in frames.
  • Iframe allow attributes delegating features that the header has already disabled.

How to set a Permissions-Policy safely

Prerequisites: an inventory of features your pages and embedded widgets use. Risk: disabling a feature that a third-party widget depends on breaks that widget, sometimes silently. Rollback: remove or loosen the specific feature entry; browsers re-read the header on each page load.

  1. Review your pages and embeds for camera, microphone, location, payment and similar use.
  2. Start with a short list that disables features you are certain you do not use, for example camera=(), microphone=(), geolocation=().
  3. Test embedded widgets such as maps, video and payments.
  4. Add allow-list entries for the origins that need a feature, using self and explicit origins instead of a wildcard.
  5. Re-run this checker and review the browser console for blocked-feature warnings.

Limits

Only the header form is examined. Iframe allow attributes belong to page content and are not visible. Only the landing response is judged, from one location, so other pages can differ, and feature names evolve, so a name unknown to this tool is shown but not interpreted. The header limits browser features; it does not change server-side behaviour.

Frequently asked questions

Is Permissions-Policy mandatory?

No. It is optional hardening, which is why a missing header is informational.

What replaced Feature-Policy?

Permissions-Policy. The syntax differs, so old values cannot be copied unchanged.

Does disabling the camera affect my users?

Only if your site or an embed uses it. Disable only what you are sure neither your pages nor your embedded widgets need.

Why is a wildcard flagged for sensitive features?

It allows every embedded origin to request the feature.

Can I allow a feature for one partner?

Yes, list that origin in the allow list for the feature.

Does the header work on old browsers?

Support varies. It adds protection where supported and is harmless elsewhere.

Scope of this tool

  • Only the domain's apex and www host are contacted over HTTPS (and port 80 where stated); redirects to any other host are reported, never followed.
  • Spectra identifies itself honestly and does not imitate a browser, so sites that block automated clients may not show their real headers.
  • A single request path (/) is examined from this scanner's network position; other pages, other nodes of a load-balanced site and other regions may differ.
  • If a header is sent more than once, only the first occurrence is examined.
  • Error and redirect responses are not judged: their headers are not representative of the site.

Written by DNS Tools editorial · Last updated 2026-10-09