Use Permissions Policy to Limit What Embedded Frames Can Request

• Inventory which embedded origins truly need camera, microphone, location, fullscreen or payment features.
• Set the page-wide ceiling with a Permissions-Policy response header.
• Delegate only the needed feature on the matching iframe, then test denied and allowed paths.

A video widget may need fullscreen. It probably does not need location. An analytics frame should not need the camera at all.

Permissions Policy lets the top page limit browser features for itself and its embedded frames. Use it to turn those assumptions into a browser-enforced boundary.

The policy is not a permission grant. It decides whether a document is allowed to ask or use a controlled feature. The user's browser permission still applies.

Start with an embed and feature inventory

List each iframe, its exact origin, its owner and the feature it needs. Include frames inserted by tag managers or consent tools. Each subdomain is another origin.

Start small. Begin with powerful features: camera, microphone, geolocation, display capture, payment and fullscreen. Browser support and default allowlists vary by directive, so verify each name against the target browsers.

Do not copy a giant deny list from a scanner and call the job finished. Unknown directives may be ignored, while an essential checkout or meeting frame can fail if its real origin was missed.

Set the page-wide ceiling

The HTTP response header controls the document and the frames beneath it. This example blocks camera, microphone and payment everywhere. It allows location only for the site itself, while fullscreen may be delegated to one video origin.

Permissions-Policy: camera=(), microphone=(), payment=(),
  geolocation=(self),
  fullscreen=(self "https://video.example")

An empty allowlist, written as (), blocks that feature. self means the current origin. A quoted URL names one allowed origin in the header syntax.

Keep the first policy small and readable. Keep it narrow. Send it on the HTML response, then confirm that a CDN, proxy or framework did not remove or duplicate it.

Narrow the matching iframe too

For a cross-origin frame, the parent header and the iframe's allow attribute work together. The effective result is the most restrictive intersection. A child cannot turn a feature back on after its parent blocked it.

<iframe
  src="https://video.example/embed/123"
  allow="fullscreen"
  sandbox="allow-scripts allow-same-origin">
</iframe>

Do not write allow="camera; microphone; geolocation; fullscreen" as a reflex. Add only the feature the component needs. If the frame navigates to a different origin, update the delegation deliberately; the original src origin is not a blanket pass for later destinations.

Keep the other boundaries

Permissions Policy does not replace iframe sandbox. It also does not control which frame origins may load, which scripts may run or where data may be sent. Use the right control for each job.

CSP can limit frame sources and other network paths. The CSP rollout guide explains how to start in report-only mode before enforcement. Audit browser extensions too. Use the browser extension audit.

A frame that can act as an authenticated user still deserves product-level controls. Apply the AI browser safety check before allowing an agent to operate inside sensitive pages.

Test both success and denial

1. Capture the current response. Save the final headers after every proxy and CDN.
2. Test the intended frame. Confirm its one required feature works after normal user permission.
3. Test a denied frame. Verify the same feature fails where it should not be delegated.
4. Navigate the frame. Check redirects, login flows and alternate subdomains.
5. Inspect target browsers. Use their developer tools and console, then repeat the user journey.
6. Record an owner. Make embed changes trigger a policy review.

This is a test plan, not a claim that TechWeb tested your pages. Run it in a staging path first. A failed camera or payment flow can look like an application bug unless the team knows to inspect policy.

Passkey flows in embedded contexts have their own WebAuthn conditions. The passkey readiness checklist helps buyers ask about recovery and platform support before renewal.

Frequently asked questions

Does Permissions Policy stop a permission prompt?

It can prevent a blocked document from using the feature. It does not grant access; browser and user permission rules still decide allowed requests.

Is the header enough for a cross-origin iframe?

Usually not. The origin must fit the parent policy and the iframe must delegate the feature with its allow attribute.

Can an iframe loosen the parent policy?

No. Its policy can only keep or narrow the access that the parent allows.

Does this replace CSP or iframe sandbox?

No. Permissions Policy controls selected browser features. CSP and sandbox cover different loading and execution boundaries.

Sources

W3C: Permissions Policy Working Draft · MDN: Permissions Policy guide · MDN: Permissions-Policy header · Chrome for Developers: Control browser features. The specification and browser support continue to evolve; verify the exact directive and target versions before enforcement.