sandbox=""是最安全起点，完全禁用脚本、表单、弹窗、存储等所有特权，连alert(1)都无法执行，DOM与父页彻底隔离，体现HTML5沙箱白名单设计原则。
iframe 不是“能用就行”的标签，嵌入即承担风险。不加 sandbox 的 iframe 等于主动开放执行权限，哪怕 src 是自家子域名，也必须默认启用沙箱并按需放行。
为什么 sandbox="" 是最安全的起点
空值 sandbox="" 表示完全禁用脚本、表单提交、弹窗、插件、顶级导航、存储访问等所有特权。此时连 alert(1) 都无法执行，DOM 与父页彻底隔离。这不是保守，而是 HTML5 沙箱机制的设计前提——白名单制，未声明即禁止。
常见误操作包括：
- 只写
sandbox（无等号无值），部分旧浏览器会忽略该属性 - 写成
sandbox="true"或sandbox="enabled"，这些值无效，等同于没加 - 在跨域 iframe 中同时开启
allow-scripts和allow-same-origin，浏览器会静默拒绝后者，但开发者可能误以为权限已生效
allow-scripts 和 allow-same-origin 绝不能共存
这是最容易踩的高危坑。一旦两者同时出现在 sandbox 属性中，iframe 就能绕过同源策略，读取父页 DOM、窃取 Cookie、调用 top.location.href 跳转全站——相当于沙箱失效。
立即学习“前端免费学习笔记（深入）”；
真实场景中应这样判断：
- 若 iframe 内容与主站同源（如
https://app.example.com/widget.html），且确需 DOM 通信，优先改用postMessage+event.origin校验，而非开allow-same-origin - 若必须同源执行脚本（如 legacy 系统迁移过渡期），确保该 iframe 完全可控，且服务端已设
Content-Security-Policy: frame-ancestors 'self' - 第三方内容一律禁用
allow-same-origin，哪怕它声称“可信”
referrerpolicy 和 loading 必须配合 sandbox 使用
referrerpolicy="no-referrer" 防止 iframe 内请求泄露当前页完整 URL（例如带 token 的路径）；loading="lazy" 延迟非首屏 iframe 加载，既降资源开销，也减少潜在攻击面。
但要注意：
-
loading="lazy"对srcdoc内容无效，仅对网络请求生效 -
referrerpolicy在 Safari 11.1+ 和 Chrome 64+ 支持良好，IE 完全不支持，需结合 CSP 的referrer-policy响应头兜底 - 若 iframe 用于埋点或统计，
no-referrer可能导致来源丢失，此时应权衡隐私与数据完整性，改用strict-origin-when-cross-origin
CSP frame-src 与 X-Frame-Options 是 sandbox 的上游防线
sandbox 控制 iframe 内部行为，而 Content-Security-Policy: frame-src 控制谁可以被嵌入——二者不可替代。如果父页 CSP 缺失 frame-src，攻击者可通过 XSS 注入任意 iframe src，绕过你页面上所有手工写的 sandbox 配置。
关键实践：
- HTTP 响应头中必须设置
Content-Security-Policy: frame-src 'self' https://trusted-widget.example.com'，不允许通配符* -
X-Frame-Options可作为兼容 fallback（如 IE11），但现代部署应以 CSP 为主，因frame-ancestors支持多源且优先级更高 - 若页面本身不应被任何外部站点嵌入（如后台管理页），直接设
frame-ancestors 'none'，比依赖前端 sandbox 更可靠
真正难的不是配置项堆砌，而是每次加 iframe 前都得问一句：这个内容非得用 iframe 吗？能不能用 API + 客户端渲染替代？如果答案是否定的，那 sandbox 就不是可选项，而是上线前必须验证的硬性条件。
