iframe 的 sandbox 属性默认禁用脚本，仅 allow-scripts 可解禁；空 sandbox 全禁用，动态设置无效；allow-scripts 不恢复内联事件处理器；allow-same-origin 与之组合需极度谨慎，易导致 xss。
iframe 的 sandbox 属性默认禁用脚本，allow-scripts 是唯一解禁方式
不加 sandbox 的 iframe 默认能执行脚本、提交表单、弹窗；但只要写了 sandbox（哪怕空值），所有能力立刻被关掉——包括 <script></script> 标签、eval()、事件处理器里的内联 JS（如 onclick="alert(1)"）、javascript: 伪协议。只有显式加上 allow-scripts 才恢复脚本执行权。
实操建议：
-
sandbox必须作为属性存在，sandbox=""和sandbox=" "效果一样：全禁用 - 多个权限用空格分隔，例如：
sandbox="allow-scripts allow-same-origin"（注意：allow-same-origin单独用不安全，和allow-scripts同时出现才可能绕过同源限制） - 浏览器不会报错提示“脚本被阻止”，而是静默失效：控制台无报错，
console.log不输出，addEventListener绑定无效 - 动态设置
iframe.sandbox属性（JS 修改）无效：必须在 iframe 插入 DOM 前就写好属性，或用srcdoc内联内容配合
只开 allow-scripts 仍不能运行内联事件处理器
这是最容易踩的坑：开了 allow-scripts，<script src="..."></script> 和外部 JS 文件能加载执行，但 onclick、onload 这类 HTML 内联事件处理器依然被屏蔽。因为它们属于“解析时执行”的行为，受更严格的策略约束。
正确做法：
- 把逻辑移到外部 JS 或
srcdoc中的<script></script>块里，用addEventListener绑定 - 避免
javascript:void(0)链接，改用preventDefault()+ 真实事件监听 - 若必须用内联 handler（如第三方无法修改的 HTML 片段），需额外加
allow-popups（部分浏览器放宽限制，但不可靠）
allow-scripts 和 allow-same-origin 组合使用要极度谨慎
单独加 allow-scripts 是相对安全的：脚本能跑，但 iframe 内文档仍被隔离在独立 origin 下（document.domain 为空，window.parent 不可读）。一旦加上 allow-same-origin，且 iframe 加载的是同域资源，它就完全等同于普通 iframe——可读写父页面 DOM、访问 localStorage、触发跨域请求。
典型风险场景：
- 加载用户可控的 HTML（如富文本预览）+
sandbox="allow-scripts allow-same-origin"→ XSS 可直接操作父页面 - CDN 返回的 HTML 被缓存后加载进沙箱 iframe，若 CDN 配置错误导致 origin 匹配，
allow-same-origin就成了后门 - Chrome 92+ 对
allow-same-origin做了强化：仅当 iframesrc是data:或blob:且与父页同源时才生效；HTTP(S) 资源即使同域也不认
调试时怎么确认 allow-scripts 是否生效
别只看脚本有没有报错，重点验证执行时机和上下文：
- 在 iframe 内 JS 中执行
console.log(window.location.origin)：如果是"null"，说明 sandbox 生效且未开allow-same-origin；如果是真实域名，则已突破沙箱 - 尝试
eval("1+1")：返回2表示allow-scripts有效；抛DOMException: Blocked a frame with origin ... from accessing a cross-origin frame是正常隔离现象 - 检查
iframe.contentWindow是否为null：如果为null，说明没加allow-same-origin且 iframe 加载了跨域资源——此时即使开了allow-scripts，你也拿不到它的window对象来主动调用方法
真正难处理的不是“怎么开脚本”，而是开之后脚本在什么上下文里跑、能触达哪些 API、是否意外获得更高权限。每加一个 allow-* 都得对应一条信任边界评估。
