No Permissions-Policy is set
Updated
What this check looks for
You have not restricted which browser features the page — and anything embedded in it — may use, such as the camera, microphone or location.
Why it matters
Nothing is wrong. It matters most when the page embeds third-party frames: without a policy, an embedded advert or widget can request features under your site's name.
When the check passes, your report says: “A Permissions-Policy limits the browser features the page may use”.
What it costs your score
This check never deducts. It reports a fact — or reports that something could not be verified — and is shown on the report without moving the score.
- Severity
- info
- Default confidence
- confirmed
- Status when triggered
- info
- Deduction
- 0 points
- Family cap
- none
- Category
- Web security
- Module
- Web security headers
- Fix owned by
- user
- In the ruleset since
- 2026.09
How to fix it
Deny the browser features the site does not use.
Without a policy, a frame you embed can ask visitors for camera, microphone or location access under your site's name.
List the features your own pages use. Most sites need none of camera, microphone and geolocation.
Send
Permissions-Policy: camera=(), microphone=(), geolocation=(), adding(self)only for features your pages use.Where an embed genuinely needs a feature, allow its origin in the header and in that
<iframe>'sallowattribute, and nowhere else.
How to confirm it worked
curl -sSI https://‹host›/ | grep -i permissions-policy — expect feature=(allowlist) entries, not the older Feature-Policy syntax
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
‹detail›
The syntax is feature=(allowlist), for example camera=(), microphone=(), geolocation=(self). An empty list denies the feature to everyone including your own page. Note this header does not accept the older Feature-Policy syntax; a value in that form is ignored.
The header switches powerful browser features off, or limits them to named origins, for the page and for every frame embedded in it. A frame can use a feature only when the header allows that frame's origin *and* the <iframe> element's allow attribute delegates it, so a site that embeds adverts, chat widgets or video can deny all of them camera, microphone, location or payment access in one line.
Start by denying what the site never uses: camera=(), microphone=(), geolocation=() is the value our security headers generator writes. Use (self) for a feature your own pages need, and name a third-party origin only where an embed must use the feature, as in payment=(self "https://checkout.example"). A feature the header does not mention keeps the browser's default, which for most powerful features is your own origin plus any frame you delegate to explicitly.
A browser ignores a feature name it does not recognise and logs a console warning, so one policy degrades safely across browsers. This check asks only whether a policy that parses is present; it does not judge which features you allowed.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.