仅校验 event.origin 不够安全，因攻击者可通过恶意 iframe 伪造 origin，且历史使用 "*" 会污染监听逻辑；必须叠加 origin 白名单严格匹配、data 类型及结构校验，回传时须用 event.origin 而非硬编码 targetOrigin。
为什么只校验 event.origin 还不够
很多人写 if (event.origin === 'https://a.com') 就以为安全了，其实这行代码在真实环境里极易被绕过。攻击者只要能诱导用户打开一个恶意页面，并在里面嵌入你的父页 iframe，就能伪造 event.origin 值——浏览器只保证它来自发送方窗口的 origin，不保证发送方是“你信任的那个父页”。更危险的是，如果父页曾经用过 "*" 发送消息，子页的监听逻辑可能已被污染，连带影响后续所有校验。
必须叠加至少两层判断：
-
event.origin必须严格等于白名单中的某一项（用===，不用.includes()或正则） -
typeof event.data === 'object'且'type' in event.data，防 JSON 解析失败或空消息触发异常 - 可选但推荐：比对
event.source是否等于你保存的 iframe.contentWindow 引用（注意 Safari 对跨域location.origin的限制可能导致该引用不可靠）
targetOrigin 设成 "*" 在 2026 年已实质失效
Chrome 128+ 和 Firefox 125+ 已强制静默丢弃 targetOrigin 为 "*" 的跨域消息，不报错、不警告、控制台也无痕迹。你以为发出去了，其实对方根本收不到。这不是兼容性问题，是浏览器策略升级后的硬性拦截。
正确做法是动态取值或配置驱动：
立即学习“前端免费学习笔记（深入）”；
- 监听
iframe.onload后，读取iframe.contentWindow?.location?.origin（注意 Safari 可能返回null，需 fallback） - 开发期可用
http://localhost:3000，但 CI 流程中应加检查：禁止"*"出现在生产构建产物中 - 若子页部署在多个子域（如
user1.example.com、user2.example.com），不要拼接通配符，改用数组白名单 +ALLOWED_ORIGINS.includes(event.origin)
iframe 加载未完成就调用 postMessage 的典型错误现象
最常见报错是 Cannot read property 'postMessage' of null，或控制台显示 Blocked a frame with origin "https://a.com" from accessing a cross-origin frame。这不是跨域本身的问题，而是你试图在 iframe.contentWindow 还没就绪时就调用方法。
可靠触发时机只有两个：
- 监听
iframe.addEventListener('load', handler)，且在 handler 中再次判空：if (iframe.contentWindow && iframe.contentWindow.postMessage) - 若 iframe 是
data:text/html或about:blank，load可能不触发，此时应让子页主动发{ type: 'ready' }握手消息，父页收到后再发业务消息 - 绝对不要用
setTimeout猜加载时间——网络延迟、JS 执行阻塞、低端设备都会导致失败
回传消息时为什么必须用 event.origin 而不是硬编码
子页调用 event.source.postMessage(reply, event.origin) 是唯一安全的回传方式。硬编码 targetOrigin（比如写死 'https://parent.com'）会导致：当父页实际从 https://staging.parent.com 嵌入时，消息被浏览器丢弃；或者中间有代理/CDN 修改了响应头，使父页 origin 偏移，回传失败却无提示。
关键点在于：
-
event.origin是浏览器提供的、与本次消息来源完全一致的字符串，可信度最高 - 回传消息也应遵循同样结构校验规则：父页收到后仍要验证
event.origin和event.data.type - 建议每条消息携带
id字段，便于父页做请求-响应匹配，避免状态错乱
真正容易被忽略的，是 origin 校验和消息结构校验必须同时存在——漏掉任意一个，就等于把通信通道的一半钥匙交给了外部。
