Cybersecurity glossary
What is Permissions Policy?
Learn what Permissions Policy is, how the HTTP header restricts powerful browser features like camera microphone and geolocation, how it differs from Feature-Policy, and how to deploy it safely.
Definition
Permissions Policy is a browser security mechanism—delivered primarily via an HTTP response header—that allows a site to control which origins may use powerful features such as camera, microphone, geolocation, payment, and other sensitive capabilities.
Why Permissions Policy matters
Modern browsers expose powerful capabilities: camera, microphone, sensors, payments, and more. Third-party scripts and iframes do not always need those capabilities. Permissions Policy lets developers deny features by default and allow them only where required.
Combined with CSP and careful iframe allow attributes, it shrinks the blast radius of XSS and malicious embeds that try to abuse device APIs.
How Permissions Policy works
Inventory feature usage
List first-party and embedded features your product actually needs.
Send Permissions-Policy
HTTP responses declare which features are allowed and for which origins.
Browser enforces allowlists
APIs become unavailable to disallowed contexts even before user prompts.
Embeds inherit constraints
Iframes need both policy permission and appropriate allow attributes where required.
Users may still consent
For allowed features, browsers can still show permission prompts.
Tune after testing
Fix broken calls and payments flows, then tighten remaining features to none.
Common directives and use cases
camera / microphone
Restrict to first-party video call origins; deny for marketing embeds.
geolocation
Allow only pages that genuinely need location; block elsewhere.
payment
Limit Payment Request API to checkout origins.
usb / sensors
Keep disabled unless a product feature requires them.
Permissions Policy vs related headers
| Header | Controls |
|---|---|
| Permissions-Policy | Which powerful browser features may be used and by whom |
| Content-Security-Policy | Which scripts/resources may load and execute |
| Referrer-Policy | How much referrer information is sent |
| X-Frame-Options / CSP frame-ancestors | Who may embed the page |
Deployment checklist
- Default-deny sensitive features that your site never uses.
- Explicitly allow features only on the origins that need them.
- Review third-party iframes and their allow attributes alongside header policy.
- Test video, payment, and location journeys after enabling the header.
- Prefer Permissions-Policy over legacy Feature-Policy for new deployments.
- Document why each exception exists so features do not creep back open.
- Monitor browser console errors for policy violations during rollout.
- Combine with CSP to address script injection and feature abuse together.
The practical takeaway
Permissions Policy restricts powerful browser features to the origins that need them. It is a least-privilege control for device and privacy-sensitive APIs.
Deny by default, allow deliberately, and test embeds carefully. If a feature is not required for the page’s job, the browser should not offer it to every script and iframe.
Related security terms
Content Security Policy (CSP)
A complementary header controlling resource loading and script execution rather than device features.
iframe security / Clickjacking
Framing attacks where Permissions Policy can limit powerful APIs inside embeds.
Cross-Origin Embedder Policy (COEP)
Another isolation-oriented policy header for cross-origin embeds.
Referrer Policy
A different HTTP policy header controlling referrer information leakage.
Frequently asked questions
What is Permissions Policy in simple terms?
Permissions Policy lets a website declare which powerful browser features are allowed—like camera or location—and which embeds may use them. It reduces surprise access by scripts and iframes.
Is Permissions Policy the same as Feature-Policy?
Feature-Policy was the earlier name. Permissions Policy is the modern successor with updated syntax and broader feature coverage.
Does Permissions Policy replace user permission prompts?
No. Browsers still prompt users for many sensitive features. Permissions Policy can disable features entirely or restrict which origins may even request them.
How do you disable a feature site-wide?
Send a Permissions-Policy header that lists the feature with an empty allowlist, for example `geolocation=()` depending on desired syntax for that feature.
Can iframes use camera if the top page allows it?
Only if policy and iframe allow attributes permit that origin. Embeds are a primary reason to configure Permissions Policy carefully.
What features can be controlled?
Common examples include camera, microphone, geolocation, payment, USB, interest-cohort/Topics-related controls where supported, and other powerful APIs listed in browser documentation.
Will a bad policy break my site?
Yes—if you disable features your product needs, flows like video calls or payments fail. Roll out with inventory and staged testing.
References
Explore authoritative guidance and frameworks related to permissions policy.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.