如何利用HTML的sandbox属性控制iframe的脚本执行权限

iframe sandbox属性默认全禁用，必须显式添加allow-scripts等权限才能执行脚本；空值或仅sandbox=""即彻底禁止alert、fetch、表单提交等所有主动行为，且内联脚本、eval、onclick均无效。

iframe sandbox 属性默认禁用所有脚本，必须显式授权

直接写 <iframe sandbox> 会彻底禁止 JavaScript 执行、表单提交、插件加载、弹窗、跨域请求等——连 alert() 都不会触发。这不是“限制”，而是“全关”。想运行脚本，必须在 sandbox 属性值里明确加上 allow-scripts。

只加 allow-scripts 仍无法执行内联脚本或 eval

即使写了 sandbox="allow-scripts"，iframe 内的 <script>alert(1)</script>、onclick="alert(1)"、eval("alert(1)") 全部被阻止。这是安全设计：sandbox 模式下，脚本只能通过外链引入（<script src="xxx.js"></script>），且该 JS 文件必须同源或带 CORS 头。

• 错误写法：<script>console.log('nope')</script> → 直接静默忽略
• 可行写法：<script src="https://trusted.example/script.js"></script> → 需服务端返回 Access-Control-Allow-Origin: * 或匹配源
• setTimeout、setInterval、Function constructor 等动态执行机制也一律禁用

allow-same-origin 不能和 allow-scripts 同时开，否则绕过沙箱

如果 iframe 的 src 是同源地址（比如 src="./widget.html"），又同时设了 sandbox="allow-scripts allow-same-origin"，浏览器会拒绝渲染，并在控制台报错：Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('file://') does not match the recipient window's origin ('null')（具体错误信息因环境而异，但本质是安全拦截）。这是因为 allow-same-origin 会让 iframe “假装”和父页同源，从而获得读写父文档 DOM 的能力，与 sandbox 设计目标冲突。

• 真要同源交互 → 别用 sandbox，改用 CSP 或其他隔离手段
• 必须用 sandbox + 脚本 → 只能加载跨域外链脚本，且不能读写父页面任何内容
• 若需有限通信 → 用 window.postMessage，且父页必须监听并校验 event.origin

常见组合与实际权限对照

单独一个 allow-scripts 最常用，但也最易误判效果。下面几个典型值对应的实际能力差异很关键：

立即学习“前端免费学习笔记（深入）”；

• sandbox="allow-scripts" → 可执行外链脚本，不可弹窗、不可发 fetch、不可访问 localStorage、不可读取 parent
• sandbox="allow-scripts allow-popups" → 支持 window.open()，但新开窗口**不继承 sandbox**，它拥有完整权限（除非自己也加 sandbox）
• sandbox="allow-scripts allow-forms" → 表单可提交，但提交目标必须是同源或允许 CORS，且不会触发页面跳转（target="_blank" 除外）
• sandbox=""（空字符串）→ 等价于 sandbox="allow-scripts allow-same-origin allow-forms ..." 全关，不是“无限制”

真正难处理的是第三方 widget 加载后又动态插入 script 标签的场景——sandbox 会在解析时就拦截，根本不会让那段 HTML 进入 DOM。这时候得提前约定好只接受外链 JS，或者换用 Web Worker 隔离逻辑。