allow-same-origin 必须与 allow-scripts 同时使用且仅对真正同源资源生效，否则无效；子页仍受 sandbox 隔离，window.parent 为 null；Chrome 126+ 已移除 document.domain；postMessage 必须等待 load 事件并严格校验 event.origin。
allow-same-origin 不能单独使用，加了也白加
浏览器会直接忽略 allow-same-origin，除非同时存在 allow-scripts，且 iframe 加载的是**真正同源**的资源（协议、域名、端口三者完全一致）。你写 sandbox="allow-same-origin"，它不报错，但也不生效——子页依然被当作跨域处理，window.parent、localStorage、document.cookie 全部不可访问。
常见错误是：给第三方页面（比如 src="https://ads.example.com/widget.js"）加上 allow-same-origin，以为能“打通权限”。实际结果是 token 被静默丢弃，还暴露了配置疏忽——攻击者可能据此判断你对 iframe 权限管理不严谨。
- 只在确认
src是你自己可控的同源 URL（如https://app.yourdomain.com/dashboard.html）时才启用该组合 -
allow-scripts allow-same-origin同时存在，才允许子页读写 localStorage、发起同源 fetch，但 DOM 访问仍受 sandbox 隔离（window.parent仍为 null） - Chrome 126+ 已彻底移除
document.domain跨域降域方案，别再试
父页发 postMessage 前必须等 load 事件
直接在 iframe 标签后立即调用 iframe.contentWindow.postMessage()，大概率失败——因为此时 contentWindow 还是 null。这不是异步延迟问题，而是 DOM 就没准备好。
正确做法是监听 load 事件，且仅在该事件触发后才获取 contentWindow：
立即学习“前端免费学习笔记（深入）”；
<iframe id="myFrame" src="https://child.example.com/app.html" sandbox="allow-scripts"></iframe>
<script>
const frame = document.getElementById('myFrame');
frame.addEventListener('load', () => {
// 此时 contentWindow 才可靠
frame.contentWindow.postMessage({ type: 'init' }, 'https://child.example.com');
});
</script>
- 别用
setTimeout硬等，不可靠；也别依赖iframe.onload属性写法（易被覆盖） - 如果子页加载失败（404/500），
load事件仍会触发，需配合error事件做兜底 - 测试环境用
http://localhost:3000，生产必须写死https://child.example.com，严禁'*'
子页收消息必须校验 event.origin，不能只看 data
只检查 event.data.type === 'auth_success' 或用 event.origin.includes('example.com')，等于把门钥匙交出去。恶意 iframe 可伪造任意 data，只要 origin 匹配就放行。
event.origin 是浏览器唯一可信的身份标识，它由 URL 协议+域名+端口组成，无法被子页篡改：
// ✅ 正确校验
window.addEventListener('message', (e) => {
if (e.origin !== 'https://parent.example.com') return;
if (e.data.type === 'login') {
// 安全处理
}
});
- 永远不用
indexOf、includes或正则模糊匹配 origin，必须严格全等 - 如果父页有多个可信来源，用数组 +
Array.includes()显式枚举，别写通配逻辑 - 收到消息后，若需回传，务必用
e.source.postMessage()+ 明确 targetOrigin，避免发给错误窗口
sandbox + allow 组合比单开 allow-same-origin 更危险
很多人以为 “开了 allow-same-origin 就等于信任”，其实更危险的是：开了 allow-scripts allow-same-origin 后，子页 JS 的 fetch() 请求中 Origin 头会显示为父页域名。如果后端只靠 Origin 鉴权，就会误判为合法请求。
- 子页一旦被 XSS 注入，就能以父页身份调用所有 API、读取 Cookie、伪造表单提交
-
allow-top-navigation和allow-top-navigation-by-user-activation都不该加；真要跳转，由父页监听postMessage后主动执行window.location.href - 广告或小工具类 iframe，最小权限应是
sandbox="allow-scripts allow-popups"，禁表单、禁存储、禁跳转父页
真正安全的起点不是“怎么打通通信”，而是“默认什么也不让做”。allow-same-origin 不是功能开关，是风险开关——开之前，得先确认子页代码完全可控、部署链路无污染、后端鉴权不依赖 Origin 头。
