# Does your site declare which browser features it may use?

By Mark Kashef, founder of Lockpick. Published 2026-10-08, updated 2026-10-08.

The browser feature check credits a declared Permissions-Policy that limits camera, microphone and other powerful features. A missing one is never reported.

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.

:::fix-prompt any
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](/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](/docs/get-started/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.

## Sources

- [How we rate findings](https://www.lockpick.app/docs/security/how-we-rate-findings), Lockpick docs, read on 2026-10-07
- [Permissions-Policy header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Permissions-Policy), MDN Web Docs, read on 2026-10-07