Permissions Policy lets a website declare limits on supported browser features for its own context and embedded content. It can help restrict capabilities such as camera or microphone access where the browser implements the relevant directive. It is a feature-use boundary, not a universal sandbox or a replacement for the browser’s ordinary user-permission process.
This guide explains how to adopt the policy deliberately on a site you operate. Begin with the features the application needs and the trust relationships of its embedded content. Verify support and actual behavior rather than assuming that every policy directive works identically in every browser.
Define the Permissions Policy requirement
Inventory browser features used by the application and its frames. Separate essential functionality from unused capabilities. A page that never needs a microphone can have a different policy from a conferencing feature that legitimately requires one.
Review third-party embeds and who controls their content. Delegating a capability to an iframe creates a relationship with that origin and component, not merely a cosmetic page element. Document why the delegation is needed.
Identify a feature owner who can resolve compatibility questions. A policy that is loosened whenever an integration fails will not preserve a meaningful boundary for long.
Understand policy versus user permission
A feature being permitted by policy does not necessarily mean the user has granted access. Browser permission, secure-context requirements, and feature-specific behavior can still apply. Conversely, user approval does not automatically bypass a policy that blocks the feature.
Do not describe an allowlist entry as silently enabling a device. The actual permission model depends on the feature and browser. Explain the boundary accurately in user-facing or security documentation.
Use the MDN Permissions Policy guide for the conceptual model and links to feature directives. Check the support of each feature you intend to control.
Start with supported, purposeful restrictions
Choose directives for capabilities the application can safely restrict. A limited example for a page that does not need either feature is:
Permissions-Policy: camera=(), microphone=()This illustrates an empty allowlist for those supported directives. It is not a universal header for every application and does not establish support in a particular browser. Test the configuration against your actual functionality.
Avoid copying a long list of unfamiliar directives as proof of security. Unsupported or obsolete entries may add confusion, while an overly broad rule can break a feature the business needs.
Review iframe delegation deliberately
A document’s policy and an iframe’s applicable configuration can interact. Review the supported mechanisms and the permitted origins for the feature. Do not assume that an iframe attribute can override every restriction imposed by the containing context.
Keep origin choices exact and documented. A capability intended for one trusted embedded service should not be granted broadly to every possible frame. Recheck the relationship when the vendor or embedding URL changes.
Test nested embedding where it matters. A simple top-level demonstration may not reproduce a real integration that involves several frames and policy layers.
Check the deployed header path
Inspect the actual page response through the production proxy or CDN. Application templates, server configuration, and edge rules can all influence headers. The browser sees the deployed result, not the file a developer last edited.
Keep policy generation consistent across relevant pages and error paths. A sensitive feature route should not accidentally inherit a permissive fallback because it uses a different application handler.
Record prior configuration and rollback steps. Compatibility failures deserve diagnosis of the specific directive and context, not deletion of the entire policy as the first response.
Test allowed and denied behavior
Use controlled pages to attempt the intended features in permitted and restricted contexts. Confirm that legitimate functionality remains available with the required user permission and that denied contexts cannot use the blocked capability.
Test the browsers and versions your product supports. Feature-policy support can vary, and a ignored directive is not an enforcement success. Document gaps and choose additional controls where the threat model requires them.
Keep test accounts and device data non-sensitive. A camera or microphone test should not collect private recordings merely to establish that a permission prompt appeared.
Keep other security controls active
Permissions Policy does not decide whether an API request is authorized, whether a script is trustworthy, or whether a server can safely process input. Maintain those controls independently. Feature restrictions cannot make an unsafe backend operation acceptable.
Content Security Policy helps govern different browser content behavior. Our CSP report-only guide explains why policy rollout needs testing and evidence. Do not treat the two headers as interchangeable protections.
Also review third-party script access to page data. A script can create risk without needing a camera or microphone, so restricting those capabilities does not solve every privacy concern.
Maintain the feature inventory
Revisit the policy when adding new features, changing embeds, or updating supported browser requirements. An application can legitimately need a previously blocked capability, but the change should have a reason and bounded scope.
Keep the approved directives, origins, test cases, and known limitations together. This makes future troubleshooting less dependent on someone remembering why a header was introduced.
Use compatibility reports and user feedback as investigation inputs. A broken workflow may reflect browser support, permission state, policy, or application logic. Identify the cause before widening access.
A practical verification scenario
Consider a page that embeds a trusted conferencing component while most other pages never need device access. Review the feature requirements separately instead of allowing every frame on the website to use the same capabilities. The conferencing route may require bounded delegation and ordinary user permission, while an unrelated marketing page can retain a more restrictive policy.
Test the approved component and a harmless unapproved frame in a controlled environment. Record which browser was used, what policy was delivered, and whether the attempted feature was available. A permission prompt alone is not the entire result; the application must also behave correctly when the user declines or the policy prevents access.
Use non-sensitive test media and avoid retaining recordings. Keep the delegation rationale with the feature owner, and recheck it when the embed origin, frame structure, or supported browser list changes. A narrow exception should remain narrow after later application work.
Frequently asked questions
Does an allowed feature bypass the user’s permission prompt?
Not generally. Policy permission and user permission are distinct parts of the feature’s requirements. Check the exact browser and API behavior.
Can this policy replace a sandbox or CSP?
No. It controls supported features under its own model. Other execution, content, and server-side boundaries need separate design.
What is a good first rollout?
Inventory the needed capabilities, restrict clearly unused supported features, and test both allowed and denied contexts. Document browser gaps and review iframe delegation before making broader changes.
