window.postMessage 如何校验 origin：跨窗口通信的来源边界与回退策略

支付页放在 iframe 里时，前端通常只需要一条消息就能把“已确认”传回订单页。但如果接收端只判断 event.data.type，任何能拿到窗口引用的页面都可能伪造这条消息。window.postMessage 解决的是跨源传递，不会替你完成身份认证；安全边界必须由发送端和接收端一起写出来。

把可信来源写成完整 origin，在接收端同时核对 event.origin、必要时核对 event.source，再校验 event.data 的结构；回复消息时不要用无约束的 *。

先确定消息要保护什么

先把资产说清楚。订单页不应该因为一条陌生的 message 就切换“支付成功”状态，支付 iframe 也不应该把订单号、用户标识或一次性结果发给任意页面。下面的示例把订单页称为 https://shop.example，把支付页称为 https://pay.example，它们只是便于阅读的示例 origin。

这里有两个方向：订单页发送初始化消息时，要限制接收目标；订单页接收支付结果时，要验证消息发送者。只写其中一边，仍然会留下可利用的空档。

消息入口先挡住陌生来源

接收端先判断 event.origin，它是发送消息时发送窗口的 origin，包含协议、主机和端口。不要使用 includes("pay.example") 这类字符串包含判断，因为相似主机名也可能通过检查。

const paymentWindow = document.querySelector("iframe").contentWindow;
const trustedOrigin = "https://pay.example";

window.addEventListener("message", (event) => {
  if (event.origin !== trustedOrigin) {
    console.warn("忽略未知消息来源", event.origin);
    return;
  }

  if (event.source !== paymentWindow) {
    console.warn("忽略未知窗口");
    return;
  }

  if (event.data?.type !== "payment:confirmed") return;
  if (typeof event.data.orderId !== "string") return;

  markOrderPaid(event.data.orderId);
});

这段代码的控制流很短：先过 event.origin，再过 event.source，最后才进入 event.data。实际项目里应把 trustedOrigin 放在配置中，并让 paymentWindow 指向你创建或确认过的那个窗口引用。

为什么 origin 通过还不够

同一个 origin 下可能存在多个窗口，尤其是页面有多个 iframe 或 popup 时。event.source 可以把来源进一步收窄到预期窗口。它不是所有场景都能使用的万能身份凭据，例如扩展环境有特殊限制，但在普通页面与已持有的 iframe / popup 引用之间，这道检查能避免把另一个窗口的同源消息混进来。

发送端不要把目标交给通配符

初始化请求也要写清目标，不要因为“反正只有一个 iframe”就把 targetOrigin 写成 *。窗口在消息发出后可能被导航到另一页；明确的目标 origin 能降低消息被意外接收的范围。

paymentWindow.postMessage(
  { type: "payment:init", orderId },
  trustedOrigin,
);

targetOrigin 要和目标页面的完整 origin 精确匹配，所以 http://pay.example、https://pay.example 和带非默认端口的地址不是同一个值。只有确实无法知道目标 origin 的特殊场景才考虑通配符；对订单结果这类数据，宁可让配置错误暴露，也不要静默扩大接收范围。

回复消息时沿用已经核对的来源

支付页收到合法初始化消息后，回复可以使用 event.source 作为窗口对象，并使用刚刚核对过的 event.origin 作为 targetOrigin。回复前仍要检查 event.data，因为来源可信不代表每条消息都符合业务协议。

window.addEventListener("message", (event) => {
  if (event.origin !== "https://shop.example") return;
  if (event.data?.type !== "payment:init") return;
  if (typeof event.data.orderId !== "string") return;

  event.source?.postMessage(
    { type: "payment:confirmed", orderId: event.data.orderId },
    event.origin,
  );
});

这里的 event.data 是输入边界，targetOrigin 是输出边界。把两者分开写，日志和测试都更容易定位：是陌生来源被拒绝，还是合法来源发来了错误消息。

把拒绝路径写进测试和日志

至少覆盖四种情况：可信 origin + 正确窗口 + 正确消息、错误 origin、正确 origin 但错误窗口，以及正确来源却缺少 orderId。拒绝时只记录来源和消息类型等必要诊断信息，不要把完整支付载荷写进生产日志。

function isPaymentConfirmed(event, paymentWindow) {
  return event.origin === "https://pay.example"
    && event.source === paymentWindow
    && event.data?.type === "payment:confirmed"
    && typeof event.data.orderId === "string";
}

验证结果应该是可观察的：合法消息只改变对应订单，错误来源和错误窗口不改变页面状态，错误字段不会触发后续业务函数。不要用“页面看起来没问题”代替这些断言。

几个容易留下空档的写法

• 用 * 发送订单结果：目标窗口被导航后，消息可能落到新的文档。
• 只校验 event.origin：多窗口场景下无法确认是不是预期的那个窗口。
• 把 event.data 直接交给 innerHTML 或命令分发器：来源检查不能替代输入处理。
• 用正则或字符串包含判断 origin：应比较完整、规范化后的固定 origin。

相关问题

postMessage 的 origin 会包含端口吗？

会。协议、主机和非默认端口共同参与匹配，开发环境的端口变化要在配置和测试中明确处理。

什么时候可以使用 targetOrigin 为 *？

只有在目标 origin 确实不可知且消息不含敏感数据时才考虑。支付结果、用户标识和控制指令不适合用通配符。

校验 origin 后还需要校验消息字段吗？

需要。可信窗口也可能因为版本不一致或业务错误发送不完整数据，字段类型检查应在触发状态变更前完成。

小结

跨窗口通信的安全边界可以落成一条可检查的链路：发送时用 targetOrigin 限定目标，接收时核对 event.origin 和 event.source，通过身份后再验证 event.data。这几道检查都不长，却能把“收到一条消息”与“允许改变订单状态”明确分开。