这个问题在做 SSO、做多站点业务、或者“主站 + 独立活动页”时经常冒出来：A 域登录了，B 域能不能直接读到 A 的 Cookie？

结论先放前面：不同主域（不同 eTLD+1）之间，浏览器不允许你直接共享 Cookie。能做的只有“换个思路实现同样的业务目的”，比如跳转换票据、统一登录中心、或者用后端做代理。

同源策略是浏览器的基本安全机制，其核心要求是：只有当请求的协议、域名和端口号完全一致时，才视为同源。

  • 对于 Cookie 来说，同源策略意味着默认情况下，Cookie 仅能在设定该 Cookie 的域名及其子域名中访问。
  • 例如，设置 Cookie 时指定 Domain=.example.com 后，example.com 及其所有子域（如 sub1.example.com、sub2.example.com）都可以共享该 Cookie。但对于完全不同的主域，如 example.com 与 anotherdomain.com，浏览器会严格阻止 Cookie 共享。

由于同源策略的限制，直接实现不同主域之间（例如 example.com 与 anotherdomain.com）的 Cookie 共享是不允许的。这是为了防止恶意站点利用 Cookie 读取其他网站的用户信息，降低 XSS（跨站脚本攻击）和 CSRF（跨站请求伪造）的风险。

跨域共享的解决方案

子域共享

如果你的需求其实是“同一主域下的多个子域共享登录态”（比如 app.example.com 和 admin.example.com），那 Cookie 是能共享的：设置 Domain=.example.com 就行。

1
Set-Cookie: sessionId=abc123; Domain=.example.com; Path=/

这意味着 example.com 及其所有子域（如 app.example.com、blog.example.com）都能访问该 Cookie。

不同主域之间的共享–替代方案

对于完全不同的主域，Cookie 这条路走不通，但业务上常见的诉求无非是“统一登录 / 统一身份”。常见替代方案有：

  • 第三方 Cookie 和单点登录（SSO）
    利用第三方认证服务器，通过统一登录接口为不同域提供认证服务。认证服务器在用户登录后，会在各个需要的域中写入相应的认证信息。
    在这种场景下，第三方 Cookie 常被使用。但需要注意的是，近年来浏览器对第三方 Cookie 趋于严格，默认可能被拦截。

  • 服务器端代理转发
    前端请求先发送到同源的代理服务器，再由代理服务器向目标域发起请求。这样可以避免浏览器的同源限制，将跨域数据的处理放到服务器端完成。

  • 跨域资源共享（CORS）
    通过服务器在响应头中设置 Access-Control-Allow-Origin 等字段，允许特定域名的跨域 AJAX 请求，从而实现数据共享。

实际项目里最常见的 SSO 方案反而是“跳转换票据”：用户访问 B 域时跳去登录中心，登录中心再把临时 code 带回 B 域，B 域用 code 换自己的 session（最终 Cookie 还是写在 B 域自己下面）。

SameSite 属性在跨域共享中的作用

SameSite 更像是“跨站请求时 Cookie 能不能被带上”的开关，它影响的是请求携带行为，不是“跨域读写”本身。

随着 Web 安全要求的提升，浏览器引入了 SameSite 属性，用于限制 Cookie 的跨站请求行为。该属性有三个取值：

  • Strict：Cookie 仅在同一站点内发送，完全不允许跨站请求携带 Cookie。
  • Lax：默认策略，大部分跨站请求（如 GET 请求）可以携带 Cookie，但某些敏感操作（如 POST 请求）不会携带。
  • None：明确允许跨站请求携带 Cookie，但必须同时设置 Secure 属性，表示仅在 HTTPS 连接下发送。

在实现跨域共享（例如第三方 Cookie 用于单点登录）的场景中，若希望 Cookie 能被跨站请求携带，就需要将 SameSite 设置为 None：

1
Set-Cookie: sessionId=abc123; Domain=.example.com; Path=/; SameSite=None; Secure

注意：

  • 设置 SameSite=None 后，浏览器会要求 Cookie 同时设置 Secure 属性，即只能在 HTTPS 下传输。
  • 不同浏览器对 SameSite 的默认策略可能略有差异，因此在设计跨站认证方案时，需要充分测试确保兼容性。
  • 另外，第三方 Cookie 这几年越来越难用（Safari ITP、Chrome 的限制逐步收紧），别把它当成“永远可用”的基石。

总结

  • 同源策略严格限制 Cookie 只能在同一域或其子域之间共享，防止跨站数据泄露。
  • 子域共享可以通过设置 Cookie 的 Domain 属性实现，但对于完全不同的主域，直接共享是不允许的。
  • 跨域共享需求可通过第三方认证（SSO）、服务器代理或 CORS 解决，但需特别关注安全性。
  • SameSite 属性是实现跨域请求安全控制的重要手段，设置为 None 并配合 Secure 可以允许跨站 Cookie 的传递，但同时也要求严格的 HTTPS 环境。

理解了“Cookie 不能跨主域共享”这个前提之后，很多方案就会清晰：要么做子域共享，要么做跳转换票据的 SSO，要么把跨域能力挪到服务端。至于 SameSite/第三方 Cookie 的限制，建议尽量早测、别临上线才发现浏览器不给你带 Cookie。

Happy Coding!