重定向到同站资源时Sec-Fetch-Site为何为cross-site？

问题背景 #

完整流程梳理：

• 1. GET https://abc.example.com:8445/desktop/container（受保护资源，触发SAML认证重定向，状态码302）
• 2. GET https://xyx.test.com:8553（完成SAML认证后重定向至https://abc.example.com:8445/desktop/sso/authcode，状态码302）
• 3. 访问https://abc.example.com:8445/desktop/sso/authcode，响应返回带Same-Site:Strict属性的认证令牌Cookie，并重定向回原始地址https://abc.example.com:8445/desktop/container（状态码302）
• 4. 再次请求https://abc.example.com:8445/desktop/container，未携带令牌Cookie触发重复认证，请求头显示Sec-Fetch-Site: cross-site

核心原因 #

浏览器标记Sec-Fetch-Site的关键是请求的发起溯源链，而非目标域名是否一致：

• 整个跳转链始于跨域的xyx.test.com，第4次请求的发起上下文会被浏览器溯源到这个跨域站点，因此被标记为cross-site
• Same-Site:Strict的Cookie规则是：仅当请求发起上下文与Cookie所在域名完全同站时才会携带。由于第4次请求被判定为跨域发起，浏览器拒绝携带该Cookie
• 当Same-Site设为None时，Cookie会在所有跨站、同站请求中被携带（需配合Secure属性），因此第4次请求能正常带上Cookie

可行解决方案 #

1. 调整跳转方式：在abc.example.com/desktop/sso/authcode页面中，用前端JS跳转（如window.location.href = "/desktop/container"）替代302重定向。这样跳转发起上下文是同站的abc.example.com，后续请求会被标记为same-site，Same-Site:Strict的Cookie可正常携带
2. 修改Cookie属性：将Same-Site设为Lax（替代Strict或None）。Lax允许在跨域发起的导航类请求中携带Cookie，安全性比None更高，同时能解决当前问题（注意Lax需配合Secure属性在HTTPS环境下生效）

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