postMessage是当前唯一无需服务端配合、能安全完成iframe跨域通信的标准方案;其核心在于双向origin校验、精确targetOrigin指定及异步消息设计,缺一不可。
直接说结论:用 postMessage 是当前唯一无需服务端配合、能安全完成 iframe 跨域通信的标准方案。但“能发”不等于“安全”,漏掉 origin 校验或乱用 "*" 就等于把数据裸奔发出去。
因为浏览器的同源策略会拦截跨域 iframe 的 contentWindow 属性读取,连 iframe.contentWindow.document 都会报 SecurityError。这不是权限没开,是浏览器硬性禁止——哪怕你只是想调个函数、读个变量,都不行。
常见错误现象包括:
Blocked a frame with origin "https://a.com" from accessing a cross-origin frame.Cannot read property 'xxx' of null,其实是 contentWindow 返回 null 或被拦截这时候别折腾 document.domain(只适用于子域场景)或 JSONP(不适用于 iframe 通信),直接切到 postMessage 路线。
接收方必须验证 event.origin,否则任何页面都能伪造消息冒充合法来源。只校验协议+域名+端口,不拼接路径,也不用正则模糊匹配。
if (event.origin !== 'https://b.com') return;
if (!event.origin.includes('b.com')) return;(会被 https://evil-b.com 绕过)if (event.origin === '*')(event.origin 永远不会是 "*",这行永远为 false)如果目标源有多个(比如测试环境用 http://localhost:3000,线上用 https://prod.com),就用白名单数组比对:
const ALLOWED_ORIGINS = ['https://prod.com', 'http://localhost:3000'];if (!ALLOWED_ORIGINS.includes(event.origin)) return;
发送前要确保 iframe 已加载完成,否则 contentWindow 可能为 null;同时避免把敏感数据明文塞进 message 参数里。
iframe.onload 或用 iframe.addEventListener('load', ...),而不是靠 setTimeout 猜时机targetOrigin,比如 iframe.contentWindow.postMessage(data, 'https://b.com')
localStorage、cookie 或用户凭证等敏感字段;如需传递 token,应走后端签发的短期有效票据,并由子页自行向自己后端校验JSON.stringify() 再发,子页再 JSON.parse()
子页调用 parent.postMessage() 时,targetOrigin 应该填父页的实际源,不是 "*",也不是空字符串。父页收到后,也要校验 event.origin 是否可信。
parent.postMessage({type: 'READY', payload: {...}}, 'https://a.com')
event.source 是子页的 window 引用,可用于后续单向通信(比如父页再发指令),但不能绕过 origin 校验直接调用其方法id 字段做请求标识,避免响应错乱最容易被忽略的一点:postMessage 是纯异步、无确认机制的。发了不等于对方收到了,更不等于处理成功。业务关键链路(比如支付跳转后等待结果)必须设计超时重试 + 回调兜底,不能只靠一次 postMessage 就认为通信已完成。