为何从Stripe跳转至Example.org时Strict模式Session Cookie未携带？

• 用户在example.org完成身份验证
• 用户访问stripe.com
• 用户点击stripe.com上的超链接返回example.org

上述步骤3中，预期用户以已认证身份加载example.org，但实际请求未携带Session Cookie；若直接在地址栏输入example.org，请求则会正确携带包含Session字段的Cookie头。

实际请求仅携带ajs_user_id、ajs_anonymous_id和foo_authenticated Cookie，缺失关键的Session Cookie。

Cookie设置详情 #

foo_authenticated Cookie #

set-cookie: foo_authenticated=true; Max-Age=86400; Path=/; HttpOnly

Session Cookie #

set-cookie: Session=YVF2WTFCQUVMZDkyU3FqZVhodjVI.8YX7wNCVx5VxlG49J4jZvRgoA6GuLRhw57GqoMJk9s0; Max-Age=2592000; Path=/; Expires=Sat, 21 Oct 2023 14:40:51 GMT; HttpOnly; SameSite=Strict

初步排查 #

曾怀疑SameSite=Strict是问题根源，但根据SameSite规则，从第三方网站点击链接跳转回第一方网站属于顶级导航，Strict模式下Cookie应当被携带。已检查stripe.com的响应头、超链接属性，未发现异常。目前计划通过中间跳转链接规避，但希望明确问题根源及根治办法。

可能原因与解决办法 #

1. Stripe页面的链接被JavaScript拦截修改 #

Stripe部分页面可能通过JS拦截超链接的默认跳转行为，改用非原生方式触发跳转（如window.location.href、history.pushState或iframe内跳转）。这种情况下，浏览器可能不判定为标准顶级导航，从而不携带Strict模式的Cookie。

解决办法：

• 用浏览器开发者工具查看跳转请求的发起方式，确认是否为正常的GET顶级导航；
• 检查链接是否带有target="_blank"，若有需确保同时设置rel="noopener noreferrer"（避免新窗口继承上下文导致的异常）；
• 若确认是JS拦截导致，要求Stripe端使用原生超链接，不添加自定义跳转逻辑，或通过top.location.href在顶级窗口触发跳转。

2. 浏览器对Strict模式Cookie的判定差异 #

不同浏览器对“顶级导航”的判定细节可能存在差异，若Stripe页面设置了特殊的安全响应头（如Content-Security-Policy），可能间接影响Cookie的携带逻辑。

解决办法：

• 临时将Session Cookie的SameSite改为Lax测试，若问题解决，可评估业务安全性后将策略调整为Lax（Lax默认允许顶级导航携带Cookie，兼容性更广泛）；
• 若必须保留Strict，可采用中间跳转页作为过渡：用户点击Stripe的链接先跳转到example.org的无认证跳转页，再从该页通过原生方式跳转到目标页面，确保浏览器判定为第一方顶级导航。

3. 跳转链接位于Stripe页面的iframe中 #

如果跳转链接在Stripe页面的iframe内部，从iframe跳转回example.org时，浏览器可能不将其视为第一方顶级导航，进而不携带Strict Cookie。

解决办法：

• 确认链接是否处于iframe嵌套结构中；
• 若在iframe内，要求Stripe将链接移至顶级页面，或通过JS在顶级窗口触发跳转（top.location.href = 'https://example.org'）。

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