空sandbox属性启用全部限制：脚本不执行、表单不提交、弹窗失效、localStorage不可读写、同源判定强制为null；需显式添加allow-scripts等白名单token才能放行对应能力。
空 sandbox 属性到底禁用了什么
不加任何值的 sandbox（即写成 <iframe sandbox> 或 <iframe sandbox="">）会启用最严隔离：所有主动行为一律禁止。这不是“默认关一部分”，而是“全部关死”。
-
<script>标签、onload、内联onclick全部失效，连alert(1)都不会弹 - 表单点击提交无响应，控制台静默失败，不报错也不跳转
-
window.open()、target="_blank"、自动播放<video autoplay>全被拦截 -
localStorage、sessionStorage、cookie读写直接抛SecurityError - 哪怕
src指向同域 HTML，origin 也会被强制设为"null"，彻底失去同源身份
allow-scripts 和 allow-same-origin 合用的真实效果
这两个 token 经常被一起写，但它们不是“功能叠加”，而是存在关键依赖关系：后者只在前者存在且 iframe 实际加载同源资源时才生效。
-
allow-same-origin单独出现无效——浏览器会直接忽略它 -
allow-scripts allow-same-origin同时存在时：localStorage可读写、fetch()可发同源请求，但window.parent和document仍不可访问（sandbox 的 DOM 隔离是硬边界） - 如果
src="https://third-party.com/widget.html"却写了allow-same-origin，该 token 被静默丢弃，既没获得权限，又暴露了配置疏忽 - 生产环境嵌第三方内容时，永远不要加
allow-same-origin；仅限确认src是https://yourdomain.com/xxx（协议+域名+端口全一致）的内部可信页面
常见功能场景的最小权限组合
别堆砌 token，每个加上的值都意味着额外攻击面。按真实需求选最窄集合：
- 只展示带 JS 的广告或图表：
sandbox="allow-scripts allow-popups"（禁表单、禁存储、禁跳转父页） - 嵌入用户反馈表单（需提交）：
sandbox="allow-scripts allow-forms allow-popups"（表单提交走 CORS，不碰allow-same-origin） - 嵌入同源管理后台（需 localStorage + 表单）：
sandbox="allow-scripts allow-same-origin allow-forms"（必须确认src真是同源 URL） - 绝对禁止 iframe 跳转父页面：
allow-top-navigation和allow-top-navigation-by-user-activation都不要加；真要跳，由父页监听postMessage后主动执行
验证 sandbox 是否真正生效的实操方法
别靠猜测或文档描述，打开开发者工具直接查：
立即学习“前端免费学习笔记（深入）”；
- 选中 iframe 元素 → 控制台输入
document.querySelector('iframe').sandbox→ 返回的是DOMTokenList对象，其.length> 0 才表示 sandbox 已启用 - 在 iframe 内运行
console.log(location.origin)：若输出"null"，说明allow-same-origin未生效或未添加 - 尝试执行
localStorage.setItem('test', '1')：若报SecurityError，说明 storage 权限确实被拦住 - 注意：
sandbox对srcdoc内容同样生效——哪怕没网络请求，内联 HTML 也受限制
最容易被忽略的一点：sandbox 不是“加了就安全”，而是“不加白加，加错更危险”。它的设计哲学是白名单，每放行一个能力，就要清楚对应风险。尤其当配合 referrerpolicy、srcdoc、CSP 使用时，token 之间可能产生意料外的交互，上线前务必在真实环境中逐项验证行为边界。
