Safari14+下第三方iframe带Cookie发送Ajax请求的解决方案

一、替代URL传参的更优方案 #

1. 跨域消息通信 + Storage 存储会话ID #

在iframe内的myapp.com页面中，通过postMessage与父页面otherbusiness.com通信，将会话ID传递到父页面存储（或直接在myapp.com的localStorage中存储）。后续发起请求时，从Storage中取出会话ID，放在请求头（比如自定义X-Session-ID或标准Authorization头）里发送给服务器。

• 关键注意事项：
  • 监听message事件时必须校验event.origin，只处理来自otherbusiness.com的消息，防止恶意站点伪造请求。
  • 服务器需要修改会话校验逻辑，从请求头读取会话ID而非Cookie。

2. 切换为Token-based认证 #

放弃Cookie会话，改用JWT或类似的令牌机制：

• 用户首次访问myapp.com完成登录后，服务器返回Token给前端，前端将Token存在内存（如应用状态管理工具）或sessionStorage中。
• iframe内的所有请求都在请求头中携带该Token，服务器通过Token校验用户身份和会话状态。

这种方式彻底摆脱对Cookie的依赖，自然规避第三方Cookie限制，但要注意：

• 做好XSS防护，避免Token被窃取（比如优先用内存存储，而非localStorage）。
• 配置合理的Token过期时间，并实现刷新Token的机制。

3. 申请First-Party Sets（长期方案） #

如果myapp.com与otherbusiness.com同属一个业务主体，可以向浏览器厂商申请加入First-Party Sets。加入后，浏览器会将两个域名视为同一方，允许Cookie在iframe中正常发送，无需修改现有Cookie逻辑。不过该方案需要符合各浏览器的准入规则，申请流程较长，适合长期规划。

二、URL携带会话ID的最佳实践 #

如果必须采用URL传参的方式，遵循以下规则降低风险：

• 仅在必要请求中携带：不要在所有URL中附加会话ID，尤其是GET请求（URL会被记录在浏览器历史、服务器日志中），优先在POST请求的请求体中传递，而非URL参数。
• 加密会话ID：对URL中的会话ID进行加密处理，服务器端接收后解密得到真实会话ID，避免明文泄露。
• 设置短有效期：给该会话ID配置极短的有效期（如5分钟），即使泄露也无法被长期利用。
• 校验请求来源：服务器收到请求时，验证Referer或Origin头，确保请求来自信任的otherbusiness.com，防范CSRF攻击。
• 使用高熵会话ID：确保会话ID是足够长的随机字符串（至少128位），避免被暴力破解。

内容的提问来源于stack exchange，提问作者Hamish Anderson