关于postMessage通信父源验证方案的安全性与可行性问询

首先，咱们拆解你的核心问题，再针对性解答你的具体担忧：

1. 两种方案的安全性对比 #

你的原方案（URL参数传递父页面地址）和新方案（document.referrer + window.parent验证）的安全性差异，核心取决于你的实际需求：

原方案的核心逻辑 #

你通过父页面脚本主动将当前页面的location.href作为host参数传递给iframe，iframe内部解析这个参数的origin，再验证postMessage的message.origin是否匹配。这种方案的优势是精准可控：只有你指定的那个父页面（也就是传递host参数的页面）能通过验证，任何其他页面即使嵌入你的iframe，因为host参数固定为原父页面地址，它们的message.origin也无法匹配，会被直接拦截。

新方案的核心逻辑 #

你通过document.referrer获取加载iframe的页面origin，再结合window.parent === message.source验证消息确实来自父窗口。但这里有个关键前提：如果你的需求是仅允许特定的可信父页面（比如你自己的官网）通信，那么新方案的安全性远不如原方案——因为任何页面都可以嵌入你的iframe，此时document.referrer会是嵌入页面的URL，message.origin也会匹配这个origin，验证会通过，相当于允许了任何嵌入页面和你的iframe通信，这和原方案“仅指定父页面可通信”的意图完全不符。

但如果你的需求是允许任何嵌入该iframe的父页面与其通信，但要确保消息确实来自嵌入它的父窗口，那么新方案的安全性是足够的：双重验证（origin匹配referrer + 消息源是父窗口）能有效防止第三方窗口冒充父页面发送消息。

2. document.referrer被拦截或失效的情况 #

确实存在多种场景会导致document.referrer不可用或异常，即使是你方脚本直接创建iframe的情况：

2.1 常见的referrer失效场景 #

• 父页面设置了严格的referrer策略：如果父页面通过<meta name="referrer" content="no-referrer">或HTTP头Referrer-Policy: no-referrer设置了完全不发送referrer，那么iframe的document.referrer会是null；如果设置的是strict-origin-when-cross-origin，当iframe和父页面跨域时，referrer只会保留父页面的origin（而非完整URL），不过这对origin验证影响不大。
• 父页面使用file://协议：本地文件加载的页面不会发送referrer，此时document.referrer为空。
• 浏览器隐私机制拦截：用户开启隐私模式、安装了拦截referrer的扩展，或者浏览器的隐私策略（比如Chrome的隐私沙箱），都可能清空referrer。
• 跨域跳转限制：如果父页面是从HTTPS页面跳转到HTTP页面（现在浏览器通常会阻止这种行为），或者跨域跳转时被浏览器限制，referrer也可能被清空。

2.2 关于恶意iframe混淆window.parent的可能性 #

完全不用担心这个问题：

• window.parent是浏览器提供的只读属性，指向iframe的直接父窗口对象，任何脚本（包括跨域的恶意脚本）都无法修改或伪造它。
• message.source是发送postMessage的窗口对象，只有当发送消息的窗口确实是你的iframe的父窗口时，window.parent === message.source才会成立。每个窗口的window对象都是唯一的，跨域情况下恶意窗口无法访问你的iframe的window.parent，也就无法冒充这个对象的相等性。

总结一下：

• 如果你的需求是仅允许特定父页面通信，原方案的安全性更高，新方案无法满足这个需求；
• 如果你的需求是允许任何嵌入父页面通信，但确保消息来源合法，新方案是可行的，但要做好document.referrer为空时的降级处理（比如拒绝所有消息）；
• document.referrer确实存在失效场景，需要提前考虑这些边界情况。

内容的提问来源于stack exchange，提问作者Francisco Ryan Tolmasky I