A modern webpage is rarely one self-contained document. Video players, maps, payment widgets, advertisements, and social embeds can all sit inside frames supplied by other companies. Some of those components may want access to sensitive browser features. Permissions Policy gives a website a way to decide which documents may use capabilities such as the camera, microphone, location, fullscreen mode, or payment interfaces.
It is an important layer of defence because it can remove access before an embedded component has a chance to ask. However, the name is easy to misunderstand: a site’s Permissions Policy does not replace your browser’s permission controls, and it cannot grant a capability that you have denied.
What Permissions Policy controls
Permissions Policy is a web platform mechanism that lets a site enable or disable specific features for its top-level page and for documents embedded inside it. The current W3C Permissions Policy specification calls these “policy-controlled features.” Each feature has a default allowlist that determines where it is available when a site has not declared a more specific rule.
A site usually delivers its rules through a Permissions-Policy HTTP response header. It can also place an allow attribute on an individual iframe. A strict header might disable geolocation and camera access for the entire page, while a narrowly written iframe rule could permit fullscreen playback for one trusted video provider.
The mechanism was formerly known as Feature Policy. Older articles and developer tools may still use that name, but Permissions Policy better reflects its role: setting an upper limit on which capabilities a document is eligible to use.
Policy and permission are two different gates
Suppose an embedded map wants your location. First, the page’s policy must allow that frame to use geolocation. If policy blocks it, the request cannot proceed. If policy allows it, the browser may still require your approval. Your browser choice remains decisive.
This two-gate model is useful:
- The website defines which parts of the page are eligible to request a feature.
- The browser applies its own security requirements and your saved decision.
- The feature works only when every required condition is satisfied.
A policy can restrict access, but it cannot silently override a denied camera or location permission. It also does not mean every listed capability is currently in use. To manage your own choices, see our browser permissions guide.
Why embedded content needs tighter boundaries
An iframe is a page placed inside another page. It often comes from a different origin, meaning a different combination of scheme, hostname, and port. Web security already separates origins in important ways, but some powerful features need an additional rule about whether an embedded document can use them at all.
Without a careful policy, a complex site may expose more capability than each component genuinely needs. A weather widget probably does not need microphone access. An analytics frame does not need the camera. A video player may need fullscreen but not geolocation. Permissions Policy lets the publisher express those boundaries explicitly.
MDN’s Permissions-Policy reference explains that the header can allow or deny features in the document and its iframes. Browser support is not identical for every directive, so responsible developers test the policies they depend on rather than assuming universal enforcement.
What a strong policy can prevent
A restrictive policy reduces accidental exposure and limits what a compromised or poorly governed third-party frame can attempt. Depending on browser support and the directives used, a site may restrict camera and microphone capture, geolocation, display capture, fullscreen mode, autoplay, payment requests, sensors, and other APIs.
It can also reduce confusing permission prompts. If an embedded frame has no legitimate reason to request location, denying the feature at the policy layer prevents that request from reaching the user. Fewer unnecessary prompts make meaningful decisions easier to recognize.
This complements other browser protections rather than duplicating them. The same-origin policy limits how documents read one another’s data. iframe sandboxing can restrict scripts, navigation, forms, and downloads. Content Security Policy controls sources and certain execution paths. Permissions Policy focuses on access to named browser capabilities.
What Permissions Policy cannot promise
A polished policy header is not a privacy certificate. It does not stop ordinary network requests, erase cookies, block all tracking, or guarantee that the site handles collected information responsibly. It only governs features that the browser recognizes as policy-controlled.
Directives and defaults also evolve. A browser may support some feature tokens and ignore others. Misconfigured rules can break useful features or create a false sense of protection. Reports of policy violations can help developers find errors, but reporting itself should be configured with data minimisation in mind.
Most importantly, a site can permit itself to request a feature. You still need to judge the visible browser prompt. If the request does not fit what you are doing, deny it. You can revisit saved decisions later through your browser’s site controls.
Practical signals for users and site owners
Users do not normally need to read response headers. The useful habit is to treat capability prompts as contextual decisions: does this page need this feature right now? Review persistent permissions occasionally and remove access you no longer use. Our guide to safer browser screen sharing covers one especially sensitive example.
Site owners should begin from least privilege. Disable features the site does not use, allow required capabilities only for the smallest relevant set of origins, and apply narrow iframe rules. Test both successful and blocked cases across supported browsers, including pages with third-party embeds.
Permissions Policy is quiet infrastructure. When designed well, it keeps unnecessary capability requests from ever reaching you and gives embedded content a smaller space in which to operate. The browser and the user remain the final guards, but a thoughtful website can make their job much easier.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.