如何从宿主应用向跨域iframe安全传递认证信息？

一、主流传递方案的安全性对比 #

window.postMessage（首选方案） #

这是跨源通信的标准安全手段，核心是严格控制通信源和加密传输内容：

• 宿主侧：等iframe加载完成后，用postMessage发送加密后的认证令牌，必须明确指定目标源（比如https://your-iframe-app.com），绝对不能用通配符*，避免信息泄露给恶意站点。
• 嵌入应用侧：监听message事件，首先验证发送方的origin是否在可信域名列表里，再解密令牌，最后一定要把令牌传给后端做二次验证。

示例代码：
宿主端：

const iframe = document.getElementById('embedded-app');
iframe.addEventListener('load', () => {
  // 用对称加密（比如AES）处理令牌，密钥由双方提前约定
  const encryptedToken = encryptAuthToken(userValidAuthToken);
  iframe.contentWindow.postMessage(
    { type: 'AUTH_TOKEN', payload: encryptedToken },
    'https://your-iframe-app.com'
  );
});

嵌入应用端：

window.addEventListener('message', (event) => {
  // 只处理可信宿主的消息
  if (!['https://trusted-host-1.com', 'https://trusted-host-2.com'].includes(event.origin)) return;
  
  if (event.data.type === 'AUTH_TOKEN') {
    const decryptedToken = decryptAuthToken(event.data.payload);
    // 必须调用后端接口验证令牌合法性
    fetch('/api/auth/validate', {
      headers: { Authorization: `Bearer ${decryptedToken}` }
    })
    .then(res => res.json())
    .then(data => {
      if (data.valid) {
        // 加载用户专属内容
      }
    });
  }
});

URL查询参数（绝对不推荐） #

别把认证令牌放在URL参数里，风险极高：

• URL会被记录在浏览器历史、服务器日志、Referrer头中，很容易被泄露；
• 跨源场景下，恶意站点可能通过iframe的src属性窃取参数；
• 令牌一旦泄露，攻击者可以直接拿着它冒充用户访问资源。

二、CSRF令牌的作用与使用场景 #

CSRF令牌是用来防范跨站请求伪造攻击的，和iframe传递认证信息不是直接绑定，但如果涉及跨源请求，就得用上：

• 如果嵌入应用需要调用宿主的后端接口，或者宿主需要调用嵌入应用的后端接口，必须在请求中带上CSRF令牌；
• CSRF令牌要和用户会话绑定，且只能放在请求头或请求体里，绝对不能通过URL传递；
• 你可以通过postMessage从宿主侧获取CSRF令牌，再在请求中携带。

三、防止用户冒充的核心手段 #

1. 后端强验证令牌：不管用哪种方式传递令牌，后端必须做严格校验——检查令牌的签名（确保未被篡改）、过期时间、用户身份绑定关系，还要验证令牌的颁发者是否是可信的宿主应用。
2. 严格验证通信源：所有跨源通信（比如postMessage）必须验证对方的origin，只处理可信域名的请求，拒绝任何未知来源的消息。
3. 使用短期令牌：采用短期有效的访问令牌，配合刷新令牌实现长期登录（如果需要），就算令牌泄露，有效期短也能降低危害。
4. 全链路加密：所有通信必须走HTTPS，防止明文被窃听；postMessage的内容也要加密，就算被中间人捕获也无法解析。
5. 限制iframe嵌入范围：
   • 宿主应用设置X-Frame-Options: SAMEORIGIN或者CSP的frame-ancestors指令，只允许可信域名嵌入自己；
   • 嵌入应用也可以设置CSP的frame-ancestors，只接受指定宿主的嵌入请求。

内容的提问来源于stack exchange，提问作者Ismail Gül