Does your site declare which browser features it may use?
The browser feature check notes when your pages send a Permissions-Policy header, which limits powerful browser features such as the camera, microphone and location. A declared policy is credited, and a missing one is never reported.
What does this check look at?
It looks at whether your pages declare which powerful browser features, such as the camera or microphone, they may use. MDN says the header provides a mechanism to allow and deny the use of browser features in a document or within any embedded frames.
Pulse and Deep scans both run it.
What does a result mean?
| What the report shows | What it means | What to do |
|---|---|---|
| Pass | A policy is declared. | Nothing. |
| Not tested | No policy was seen. It is not counted against you. | Optional. Turn off features you never use. |
A declared policy is credited and a missing one is never reported, because absence does not show a feature is exposed.
How serious is a finding?
Treat this as a hardening gap. It makes an attacker’s job easier but gives them no path of its own, so fix it after anything more direct. Confidence starts low, because it is inferred from headers or declarations rather than shown directly. The report lists what to fix by how directly someone could use it, not by the severity label.
What does a confirmed finding have to show?
| Part | For this check |
|---|---|
| Where it starts | Content or a frame an attacker can influence |
| The protection that should stop it | A browser protection header is missing or weak |
| What is reached | How browsers treat your pages |
| What follows | A hardening gap; no exploit was shown |
Which standards does it relate to?
| Standard | Reference |
|---|---|
| OWASP Top Ten | A02:2025 Security Misconfiguration |
| CWE | CWE-693 |
Each one is a related control, not a verification. A scan sees what anyone online can see, so it never proves a whole requirement is met.
Fix it with your AI
Turning off features you never use is cheap, and it limits what an injected script or embedded frame could ask for.
Add a Permissions-Policy header to my site that turns off powerful browser features I do not use. Check my code and embedded widgets for camera, microphone, geolocation, payment, USB and fullscreen use first. Disable every feature nothing uses, for example camera=(), microphone=(), geolocation=(), and keep the ones a real feature needs. Show me the header and which features you kept.How to check
Say Atlas, our example app at atlas.example, never uses the camera or microphone. Declaring that costs one header, and the check credits it.
The free quick check covers this on your homepage with no account, and a Pulse scan from your account adds your scripts and public records. Pulse or Deep explains the difference.
Questions people ask
Why is a missing policy not a finding?
Browsers already ask visitors before using most powerful features, so the absence of a policy does not show anything is exposed.
Will this break an embedded video call or payment widget?
It can, if that widget needs a feature you turned off. Keep the features your embeds use.
See what your site shows from outside
A quick check reads your homepage the way a visitor would and gives you a score. No account needed.
Check your siteSources
- How we rate findings Lockpick docs, read on October 7, 2026
- Permissions-Policy header MDN Web Docs, read on October 7, 2026