Yes. Use the iframe allow attribute to name the browser features each embed may use, and block the rest. A product video needs fullscreen at most. A store locator may need location. Nothing on a product page should get the camera or microphone unless the feature plainly needs it.
What Permissions Policy does
MDN describes Permissions Policy as a way for developers to declare what functionality can and cannot be used on a website. It is similar to Content Security Policy but controls features instead of security behavior, and it helps compose third-party content more safely.
It works in two ways: the Permissions-Policy HTTP header controls feature use in responses and any embedded content, including iframes, and the allow attribute on an iframe controls feature use for that frame only. The two are separate but related.
MDN gives examples of what you can restrict, such as sensitive devices like the camera or microphone, and which iframes may use fullscreen. It also marks the feature as experimental and not Baseline, because browser support varies, so check the support table before relying on it.
Which embeds on a store need what
| Embed | Likely needs | Should not need |
|---|---|---|
| Product video | Fullscreen | Camera, microphone, location |
| Store locator map | Geolocation | Camera, microphone |
| Virtual try-on or AR | Camera, possibly | Location, microphone |
| Chat or help widget | Often nothing | Camera, microphone, location |
| Review widget | Nothing | Every sensitive feature |
Syntax in plain terms
MDN's general form is allow equals a directive followed by an allowlist. For example, to block geolocation for a frame, set the allow attribute to geolocation with the value none. To allow your own origin plus named origins, list self and the other addresses. To set several features, separate them with semicolons.
MDN also recommends specifying the widest acceptable support for a feature in the HTTP header, and then specifying the subset you need in each iframe.
Steps for a store
- List every iframe on product, cart and checkout pages. Capture the live page to find ones added by apps.
- For each, write down the features the embed genuinely needs.
- Set a header that turns off sensitive features sitewide by default.
- Add allow attributes only on the frames that need an exception.
- Test on the main browsers you support, since MDN notes limited availability.
- Record the decision in the tag register.
How this fits with other controls
The allow attribute limits browser features. It does not stop a script in a frame from doing other things inside that frame. Pair it with the sandbox attribute, a Content Security Policy that limits where frames can load from, and a decision about whether the embed belongs on the page at all. The iframe versus script tag decision guide and our post on the Permissions-Policy header cover these.
Where Safeguard fits
Safeguard's SBOM and dependency scanning covers packages in your build, and its policies can enforce rules on them. Headers and frame attributes are page-level settings you manage in your server and templates. A free scan is at gold.safeguard.sh/scan.
Quick check
Does the allow attribute replace the sandbox attribute?
No. They are different controls. The allow attribute governs browser features, and sandbox restricts the framed document more broadly.
Is Permissions Policy supported everywhere?
Not fully. MDN lists it as limited availability, so test the browsers your shoppers use.
Sources
Last reviewed: 19 October 2026.
