iframe 不是安全策略的解决方案，它只是内容嵌入机制；真正起作用的是 csp、sandbox 属性、allow 权限列表及 postmessage 配合校验 origin 等显式配置。
iframe 本身不解决安全策略，反而可能放大风险
直接说结论：iframe 不是安全策略的解决方案，它只是内容嵌入机制。浏览器的同源策略（Same-Origin Policy）依然生效，跨域 iframe 默认无法被父页面读取或控制——这不是“解决了”，而是“被策略拦住了”。真正起作用的是 Content-Security-Policy、sandbox 属性、allow 权限列表这些显式配置。
跨域 iframe 里父页调用子页 JS 报错：Uncaught DOMException: Blocked a frame from accessing a cross-origin frame
这是最典型的误用场景：以为加了 iframe 就能自由通信。实际只要协议、域名、端口任一不同，window.contentWindow 或 document 访问就会被拒绝。
- 必须双方都主动配合才能通信：
postMessage()是唯一安全可行的方式 - 子页面需监听
message事件，并校验event.origin（不能只信event.source） - 父页发消息时，目标 origin 不能写成
'*'，尤其涉及敏感操作时 -
document.domain方案已废弃，Chrome 126+ 完全移除支持，别再试
sandbox 属性不是“开个白名单就万事大吉”
sandbox 确实能限制 iframe 行为，但默认值是禁用一切（包括脚本、表单提交、弹窗），启用某项就得显式加对应 token，比如 sandbox="allow-scripts allow-same-origin" —— 这里藏着两个关键陷阱：
-
allow-same-origin一旦加上，该 iframe 就被视为同源，能绕过大部分隔离，此时若内容可控性不足（比如加载第三方广告），等于主动打开 XSS 渗透面 -
allow-scripts和allow-forms组合后，iframe 内 JS 可发起任意 fetch 请求，且 origin 显示为父页域名（因allow-same-origin），后端鉴权容易误判 - 没加
sandbox的 iframe，等同于完全信任其内容；加了但配错，可能比不加更危险
CSP 的 frame-ancestors 指令才是真正的“谁可以嵌我”控制
如果你担心自己的页面被别人用 iframe 套壳（点击劫持、SEO 盗用），靠前端 JS 判断 top !== self 并跳转是无效的——攻击者可加 sandbox="allow-scripts" 或用 document.write 绕过。必须由服务端响应头控制：
Content-Security-Policy: frame-ancestors 'self';
或者只允许特定域名：
Content-Security-Policy: frame-ancestors https://trusted.example.com;
-
frame-ancestors优先级高于X-Frame-Options，后者已逐步被弃用 - 该指令对 iframe 加载目标页生效，不是对父页生效——想防被嵌，得在被嵌页面的响应头里配
- 如果用了
frame-ancestors 'none'，连iframe自己嵌自己都不行，调试时容易懵
安全从来不是加个标签就完事的事，iframe 的每个属性、每条 CSP 指令、每次 postMessage 都得清楚知道它在哪个环节放行了什么权限。稍不留意，隔离区就变成跳板机。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
