Permissions Policy
Permissions Policy lets a page declare which browser capabilities — camera, geolocation, fullscreen, and more — are allowed on itself and the origins it embeds, pruning attack surface by default.
Definition
Permissions Policy (formerly Feature Policy) is a response header that controls availability of powerful web platform features per origin and per frame. The page can allowlist origins for a feature, disable it entirely, or delegate it selectively to embedded iframes, which must also request permission via the allow attribute.
Context and scope
Used by sites embedding third-party widgets, by platforms hosting untrusted content in iframes, and by any team wanting to make capability misuse fail closed rather than relying on nothing being requested.
Common misconceptions
- Permissions Policy grants capabilities — it only restricts; the underlying feature still needs its own user permission or API call
- The header alone covers iframes — embedded frames need matching allow attributes for delegated features
- It duplicates CSP — CSP governs content sources, while Permissions Policy governs browser capabilities like camera and sensors
Anti-patterns
- Embedding ad and widget iframes with default-allow everything and no policy header on the parent page
- Delegating camera or geolocation to an embedded origin without validating that origin is still the business you approved
- Assuming an unknown feature token in the header fails safe across all browsers versions
Related concepts
Related examples
Authoritative source
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Permissions-Policy
What it is
Browsers expose powerful features that default to available-on-request. Permissions Policy flips the model: the top page declares the allowed set per feature, and any origin or frame outside the set gets the feature as if it did not exist. This shrinks what an injected script or rogue embed can even attempt.
How it works
The header lists directives such as camera or geolocation with an allowlist of origins, or self, or none. Iframes receive capabilities only through both the parent policy and their own allow attribute. Feature detection calls in denied contexts behave as unsupported rather than throwing policy errors, keeping detection graceful.
When to use it
News and content sites embedding third parties should deny capabilities they never use. Platforms embedding user content should allow only the specific features that content needs, such as fullscreen for a video embed. The deny-by-default posture converts misconfigurations into loud failures.
Pitfalls
The header names evolve as the web platform grows, and unknown tokens are ignored, so review the list periodically. The iframe allow attribute is a separate delegation path that must stay in sync. Feature detection in denied frames returns false, which can confuse analytics that assume support.