跨域 iframe 通信唯一可靠方式是 postmessage；sandbox 和 csp 才是安全核心防线，需严格配置 targetorigin、event.origin 校验、权限最小化及双向 frame-ancestors 隔离。
iframe 跨域通信只能靠 postMessage，别试其他路
浏览器同源策略下，iframe.contentWindow、iframe.contentDocument 一访问就报 Blocked a frame with origin "https://a.com" from accessing a cross-origin frame。这不是配置问题，是浏览器硬性拦截。任何试图绕过它的方案（比如 document.domain）在 Chrome 126+ 已被彻底移除，强行用只会白忙活。
真正可用且全浏览器支持的唯一通道就是 postMessage。它不是“可选方案”，而是事实标准——没它，跨域 iframe 就只能单向展示，无法交互。
- 父页发消息前必须监听
load事件，否则iframe.contentWindow可能为null，调用postMessage静默失败 - 发送时第二个参数
targetOrigin严禁写'*'；哪怕测试环境用http://localhost:3000，生产也得明确写成https://child.example.com - 子页面收消息时，
event.origin是唯一可信身份标识；只校验event.data.type或用includes()匹配域名，等于开门揖盗
sandbox 属性不是加了就安全，配错比不加更危险
sandbox 默认值是空字符串，意味着禁用脚本、表单、弹窗、插件等一切能力。但开发者常犯两个致命错误：
- 加了
allow-same-origin却没评估内容可控性——一旦子页被注入恶意代码，它就等同于父页同源，可读取 Cookie、调用父页 API、甚至发起伪造请求 - 组合
allow-scripts allow-same-origin后，子页 JS 的fetch请求origin头会显示为父页域名，后端若仅靠 Origin 鉴权，可能误判为合法请求 - 没加
sandbox的 iframe，等于完全信任其内容；加了但只写sandbox="allow-scripts"，反而给了脚本执行权却没限制其网络行为，风险面反而扩大
allow 属性要按需开，别一股脑全放行
allow 控制的是 iframe 内部可启用的特性权限，和 sandbox 协同生效。常见误用是把所有功能都打开：
-
allow="geolocation microphone camera"—— 用户没点授权前就声明，会触发浏览器权限弹窗骚扰；实际要用时再动态加更合理 -
allow="fullscreen"和allowfullscreen属性重复，后者已废弃；现代写法只用allow="fullscreen" -
allow="payment-request"必须配合子页调用PaymentRequestAPI 才有意义，纯展示页面加了也没用，还暴露了支付能力意图 - 敏感操作如
clipboard-read、clipboard-write应严格限制，尤其当 iframe 加载第三方广告或小工具时
CSP 的 frame-src 和 frame-ancestors 才是源头防线
iframe 本身不提供安全策略，它只是载体。真正的防护锚点在 HTTP 响应头或 <meta> 标签里：
-
Content-Security-Policy: frame-src 'self' https://maps.google.com https://player.vimeo.com—— 控制谁可以被嵌入；漏掉一个可信域名，攻击者就能用恶意镜像站替换 -
frame-ancestors 'none'或frame-ancestors https://trusted-parent.com—— 防止你的页面被别人 iframe 嵌套，对抗点击劫持；X-Frame-Options已逐步被弃用，优先用 CSP - 如果子页由你完全控制，应在子页响应头中也设
frame-ancestors，形成双向隔离；否则父页再严，子页被挂马也白搭
最易被忽略的一点：CSP 策略对 srcdoc 内联内容无效，这类 iframe 不走网络请求，绕过 frame-src 检查——所以含用户输入的 srcdoc 必须做 HTML 实体转义，否则直接触发 XSS。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
