allow属性控制iframe可调用的浏览器api，如camera、microphone、geolocation、clipboard-read/write、fullscreen、payment等，是原生html属性，不依赖csp或sandbox，但需与之协同；值格式为"feature 'self'; feature https://example.com"，来源限制对部分特性生效，省略则默认禁用多数敏感api。

allow 属性控制哪些浏览器 API 可被 iframe 调用

allow 是 iframe 的原生 HTML 属性，不依赖 CSP 或 sandbox，但它直接决定子页面能否调用特定浏览器 API。比如写了 allow="geolocation"，但子页面调用 navigator.geolocation.getCurrentPosition() 仍会抛出 NotAllowedError——不是代码写错了，而是用户没点授权弹窗，或者页面没获得焦点。

它管控的不是脚本执行权，而是「功能开关」：camera、microphone、clipboard-read、clipboard-write、fullscreen、payment、accelerometer、gyroscope 等都归它管。这些特性原本属于 Feature Policy，现在已被 Permissions-Policy HTTP 头取代，但 allow 在 iframe 上依然完全有效，且所有主流浏览器（Chrome 84+、Firefox 82+、Safari 16.4+）都支持。

• 没写 allow 或写成 allow=""，等价于全部禁用——这是浏览器默认安全策略，不是 bug
• allow="fullscreen" 这类不涉及跨源数据的特性，来源限制会被忽略
• allow="clipboard-write *" 在 Chrome 95+ 会被静默降级为 clipboard-write 'self'，第三方域名实际无法写入

allow 值的格式必须匹配使用场景

allow 的值是字符串，语法为 "feature1 'self'; feature2 https://a.com https://b.com"，多个策略用分号分隔，每个策略后可跟来源列表。来源只对部分特性生效（如 clipboard-read、payment），而 autoplay、fullscreen 不校验来源。

常见写法：

• 'self'：仅允许同源（协议+域名+端口完全一致）子页面启用该功能
• https://trusted.example.com：精确指定一个或多个域名，空格分隔
• 'none'：显式禁用某特性，例如 allow="microphone 'none'"
• *：理论上允许所有来源，但多数敏感特性（如 microphone）在现代浏览器中已默认拒绝，即使写了也无效

错误示例：allow="clipboard-write *" 看似放开权限，实则 Chrome 会自动收紧；allow="geolocation https://example.com" 若子页面来自 https://sub.example.com，也会失败——子域名不算同源，必须写全。

Prezi

一款以动态画布和视觉叙事为特色的演示文稿制作工具，支持通过非线性布局组织内容并制作更具互动性的演示。

下载

和 sandbox、Permissions-Policy 如何协同

sandbox 和 allow 解决不同层面的问题：sandbox 控制脚本执行、表单提交、插件加载等基础能力；allow 则在 sandbox 放开的前提下，进一步声明「哪些高级 API 可用」。两者不互斥，常一起用：

<iframe src="https://widget.example.com" sandbox="allow-scripts allow-same-origin" allow="clipboard-read 'self'; payment https://pay.example.com"></iframe>

注意：sandbox 若没加 allow-same-origin，'self' 就失效；若用了 sandbox 但没开 allow-scripts，那 allow 再宽也没用——子页面根本跑不了 JS。

HTTP 响应头 Permissions-Policy 作用范围更广（整个页面或响应域），而 allow 只作用于当前 iframe。当两者冲突时，更严格的策略胜出。比如响应头设了 geolocation=()（禁止所有来源），iframe 却写了 allow="geolocation"，最终仍不可用。

容易被忽略的兼容性与调试细节

很多问题不是配置错，而是时机或上下文不对：

• clipboard-write 要求页面有焦点且由用户手势触发（如 click、keydown），单纯 onload 里调用必失败
• autoplay 必须配合 muted 属性，否则即使写了 allow="autoplay" 也会被静音拦截
• 移动端 Safari 对 microphone 和 camera 的 allow 声明支持较晚（iOS 16.4+），旧版本直接忽略
• 调试时看控制台报错类型：NotAllowedError 是权限拒绝，SecurityError 是上下文不合法（如非 secure context 下调用），DOMException: Document is not focused 是焦点缺失——每种对应不同修复路径

真正麻烦的不是怎么写 allow，而是确认子页面是否满足所有前置条件：HTTPS、用户手势、焦点状态、父页面是否被 sandbox 限制过严、以及目标浏览器是否真正支持该特性组合。