Security
Permissions-Policy
Locks down browser features — camera, mic, geolocation, payment, FLoC — so a compromised script can't quietly turn them on. Replaces the older Feature-Policy header.
What it is
Permissions-Policy is a response header (replacing Feature-Policy) that allow-lists which origins may use which browser features. Default is 'same-origin only' for most features, but tightening to () (none) is the safe deploy.
Why it matters
If you don't use the camera, you should not be granting third-party iframes or compromised scripts the right to ask for it. Costs nothing; closes a class of consent-bypass attacks.
Who it applies to
Every site — the default-deny posture is one line of config.
How WQI scores it
Web Quality Index considers this standard satisfied when the supporting factor passes.
| # | Factor | Status |
|---|---|---|
| 4 | Security headers (HSTS, CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy, X-Content-Type-Options) | live |
Related standards
- See also
- Security headers , CSP 3 , Referrer-Policy
Standards that share factors with this one
Auto-computed from overlapping factor tickets in satisfiedBy, excluding standards already listed under "See also" above. Strong overlap suggests these standards rise and fall together when sites are scored.
Other references
- guidance MDN — Permissions-Policy
Examples
Permissions-Policy: accelerometer=(), autoplay=(), camera=(), display-capture=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), midi=(), payment=(), usb=(), interest-cohort=()Empty allow-lists disable the feature for the page and every embedded iframe. Loosen one feature at a time, only when something actually breaks.