Loading...
WebShield Audit
Low severity
Missing Permissions-Policy
Formerly "Feature-Policy", this header allows you to enable or disable browser features and APIs (like Camera, Microphone, Geolocation, USB).
Business risk
If your site gets XSS'd, the attacker can try to access the user's webcam or microphone. Explicitly disabling these features limits the "blast radius" of a compromise. It also prevents third-party iframes (ads) from accessing these sensors without your knowledge.
Technical details
The syntax is `feature=(allowlist)`. Using `()` means "nobody". Recommended baseline: disable powerful features you don't use.
How to detect it
Permissions-Policy ships as a single HTTP response header. Absence of the header means every feature defaults to the browser's permissive default. Check with curl and inspect which features you actually need open.
Read the header
curl -sI https://yourdomain.com | grep -i permissions-policyAudit which features your app actually uses
grep -rE "navigator\.(geolocation|mediaDevices|usb|bluetooth)|new PaymentRequest" ./srcCommon pitfalls
- Using the old `Feature-Policy` syntax (`geolocation 'none'`). The modern header is `Permissions-Policy: geolocation=()`. Most browsers have dropped support for the old one - check your header name.
- Leaving powerful features unrestricted on marketing pages. A compromised analytics script on a page with no camera use can still try to call `getUserMedia()` unless the policy blocks it.
- Forgetting to allow your own origin when you do need a feature. `camera=()` denies everything including self. Use `camera=(self)` to permit the top-level document.
- Not setting the policy on third-party iframes. Powerful features can only be used in a cross-origin iframe if the parent explicitly delegates via `allow="camera; microphone"` on the iframe element.
- Listing features the browser does not recognise. Unknown tokens are ignored silently. Validate against the MDN feature directory before shipping.
Remediation guide
External references
Frequently asked questions
Permissions-Policy vs Feature-Policy?
Feature-Policy is the deprecated predecessor. Chrome dropped support for it in 2024; Firefox never implemented it. Use `Permissions-Policy` exclusively and use the `feature=()` syntax, not the space-separated `feature 'none'` syntax.
Will this break third-party embeds?
Only if those embeds need features your policy blocks. Check the iframe `allow` attribute on your embeds (YouTube needs `autoplay`, `encrypted-media`; Stripe needs `payment`). Grant those features via `allow=` on the iframe, and leave the default document policy strict.
What is a reasonable baseline?
Disable features you do not use: `camera=(), microphone=(), geolocation=(), payment=(), usb=(), magnetometer=(), accelerometer=(), gyroscope=()`. This blocks the highest-risk APIs and can be relaxed per-feature as needed.
Keep going
Verify your fix
Applied the configuration change? Run a live scan to confirm the vulnerability is patched.