iframe的核心用途是在当前页面安全嵌入独立文档，适用于第三方地图、广告、视频等跨域内容；必须配合sandbox等防护机制，否则易引发XSS、点击劫持等风险。
iframe 的核心用途就一个：在当前页面里安全地嵌入另一个独立文档。它不是装饰，也不是“锦上添花”的可选项——当你必须加载第三方地图、广告、视频、报表或跨域表单时，iframe 往往是唯一可行的原生方案。
但直接用 src 加载，等于把门敞开；不加防护的 iframe，可能让恶意脚本跳转顶层页面、窃取 localStorage、伪造点击劫持。真正关键的不是“能不能嵌”，而是“怎么嵌才不会出事”。
sandbox 属性默认行为到底禁了什么
空值 sandbox="" 不是“没配”，而是最严隔离模式。它会让嵌入内容彻底失去运行能力，哪怕只是一行 alert(1) 都会静默失败。
-
script标签和内联事件（如onclick）全部失效 - 表单
submit被拦截，按钮点击无响应 -
window.open()、target="_blank"、top.location.href全部被拒 - 无法读写
localStorage、sessionStorage、cookies -
fetch和XMLHttpRequest请求发不出去 - 自动播放的音视频被强制暂停（即使
autoplay存在）
这状态下的 iframe，只适合展示纯静态 HTML（比如用 srcdoc 内联的说明页），或者作为完全受控的渲染容器。
立即学习“前端免费学习笔记（深入）”；
常见 allow- token 的风险与适用场景
启用任何 allow- 权限，都是在松动沙箱边界。每个 token 都得问一句：“这个 iframe 真的需要它吗？”
-
allow-scripts：必须搭配allow-same-origin才能访问父页面 DOM，但单独启用已足够让脚本执行。广告、图表组件常用，但务必确认脚本来源可信 -
allow-same-origin：⚠️ 危险！一旦启用，同源 iframe 就能绕过同源策略，读写父页面document、cookies、storage。仅限你完全控制的子域名页面（如widget.yoursite.com）且需共享登录态时使用 -
allow-forms：只解禁表单提交，不赋予网络请求权限（仍受 CORS 限制）。问卷、搜索框等交互组件可用 -
allow-popups：允许调用window.open()，但新窗口默认也被沙箱化。建议和allow-scripts同时启用，否则弹窗里 JS 仍不可用 -
allow-top-navigation：允许修改top.location—— 支付完成页跳转必需，但也意味着能把你整个页面重定向到钓鱼站，慎用
组合示例：sandbox="allow-scripts allow-forms" 是较常见的平衡点：支持交互，但不放行跳转、不暴露 DOM、不共享存储。
必须配合使用的防护手段
sandbox 不是银弹。它只管 iframe 内容本身，不管请求头、不拦 referrer、不防主页面被嵌套。
-
referrerpolicy="no-referrer"：防止 iframe 内资源请求泄露当前页面 URL（比如埋点接口带出用户路径） -
loading="lazy"：非首屏 iframe 延迟加载，减少初始攻击面和资源浪费 - 优先用
srcdoc替代src：内联 HTML 字符串，彻底规避外部资源加载风险（适合简单提示、静态卡片） - 服务端响应头加
X-Frame-Options: DENY或Content-Security-Policy: frame-ancestors 'none'：从源头禁止你的页面被别人用iframe嵌入，和 sandbox 形成双向防护
sandbox 的复杂点不在语法，而在于权限粒度太细、组合后果难预判。比如 allow-scripts allow-same-origin 看似只是“允许同源脚本”，实际等于给了 iframe 完整 DOM 控制权——它能监听键盘、劫持表单、伪造点击。很多线上事故，都源于开发人员只看“功能跑通了”，没验证“权限是否最小化”。
