Cookie的SameSite设为Strict对跨子域Web应用及微服务的影响

如果FE（比如fe.example.com）和BE（比如be.example.com）是同一主域下的不同子域，把Cookie的SameSite设为Strict会带来这些问题：

• 跨子域请求带不上Cookie：浏览器对SameSite=Strict的Cookie限制极严，只有发起请求的页面域名和Cookie的域名完全一致时，才会携带该Cookie。哪怕是同主域的不同子域，FE发往BE的AJAX、表单提交等请求，都不会带上这类Cookie。
• 登录与授权直接失效：要是BE依赖Cookie识别用户（比如存储Session ID），FE的所有跨子域请求都会因缺少Cookie被判定为未登录，要么返回401错误，要么跳转登录页，FE与BE完全无法正常交互。
• CORS白名单无法解决此问题：CORS仅管控跨域请求的权限范围，而SameSite是浏览器层面的Cookie安全策略，两者互不干涉。哪怕把所有子域加入CORS白名单，浏览器依然会严格执行SameSite=Strict的规则，不会跨子域携带Cookie。

若微服务分布在同一主域的不同子域（比如service-a.example.com、service-b.example.com），同时启用这两个属性，影响分场景来看：

1. 前端直接调用跨子域微服务 #

和FE调用跨子域BE的情况完全一致：

• 浏览器不会携带SameSite=Strict的Cookie，请求会因缺少身份凭证被拒绝，即便配置了CORS白名单也无效。
• Secure=true要求Cookie仅在HTTPS连接下传递，若FE或微服务使用HTTP协议，浏览器会直接忽略该Cookie，连同域请求都无法携带。

2. 微服务后端之间的直接调用 #

这类请求由服务端HTTP客户端发起，不受浏览器SameSite规则约束，但Secure=true会带来限制：

• 若微服务之间用HTTP通信，遵循规范的HTTP客户端会忽略标记为Secure=true的Cookie，依赖Cookie做授权的服务间调用会直接失败；只有使用HTTPS协议时，Cookie才会正常传递。
• 若微服务共享主域的Cookie（比如example.com下的全局身份凭证），服务端请求要携带该Cookie的话，需在HTTP客户端中手动配置——毕竟浏览器的SameSite规则管不到服务端自身发起的请求，SameSite=Strict对这种场景无影响。

3. 跨子域共享Cookie彻底失效 #

要是多个微服务依赖主域的共享Cookie（比如example.com设置的Cookie）实现登录态或会话共享，前端发起的跨子域微服务请求完全带不上该Cookie，导致不同子域的微服务无法共享用户身份，服务间的协作逻辑直接断裂。

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