跨域请求时，如何让浏览器自动携带 Cookie？需要满足哪些条件？

1. 引言：两个小区的“门禁卡”

想象你住在A小区，想去B小区串门。B小区的门禁系统很严格：除非你主动出示门禁卡（Cookie），并且B小区提前在访客名单上登记了A小区的来访许可（CORS 配置），否则保安不会放你进去。即使你揣着门禁卡，保安也可能因为你没有“打招呼”而拒绝。

这就是跨域请求携带 Cookie 的真实写照。浏览器为了安全，默认禁止跨域请求携带 Cookie。如果你想实现“跨域登录态共享”（比如前后端分离架构、单点登录），就必须满足一系列条件。本文将带你彻底搞懂跨域携带 Cookie 的机制、条件和最佳实践。

2. 问题背景：为什么跨域默认不带 Cookie？

2.1 同源策略与 Cookie 的“地域限制”

浏览器有个重要的安全机制——同源策略。它限制了一个源的网页只能访问同源的资源。对于 Cookie 来说，浏览器默认只会在同源请求中自动携带，跨域请求时则不会。

为什么这样设计？试想，如果你在a.com上登录后，访问b.com时，b.com的恶意脚本也能通过跨域请求自动带上你的a.comCookie，后果不堪设想。因此，浏览器默认禁止跨域携带 Cookie，这是保护用户凭证的第一道防线。

2.2 需求场景

但在实际工程中，我们有时确实需要跨域共享凭证，例如：

• 前后端分离：前端web.example.com，后端 APIapi.example.com
• 单点登录（SSO）：多个子域auth.example.com、app1.example.com、app2.example.com

这时，我们需要主动“告诉”浏览器：这个跨域请求是安全的，请带上 Cookie。

3. 前置知识：跨域请求与 Cookie 的基础概念

在深入解决方案前，先明确几个概念：

• 同源：协议（http/https）、域名、端口完全相同。
• 跨域：协议、域名、端口任一不同。
• CORS（跨域资源共享）：一套让服务器声明“允许哪些源访问”的机制。
• Cookie 的自动携带：同域请求默认携带；跨域请求默认不携带。

4. 核心原理：跨域携带 Cookie 的三大条件

要让浏览器在跨域请求中自动携带 Cookie，必须同时满足三个层面的条件，缺一不可。

4.1 条件一：服务端明确允许携带凭证

服务器必须在响应头中添加：

Access-Control-Allow-Credentials: true

关键约束：如果允许携带凭证，Access-Control-Allow-Origin不能为*，必须指定具体的请求源（如https://a.com），且要与请求的Origin头严格匹配。

4.2 条件二：客户端明确告知“请携带”

前端在发起请求时，必须显式设置凭证选项：

4.3 条件三：Cookie 自身允许跨站发送

Cookie 的SameSite属性不能是Strict，否则即使在 CORS 条件满足时，也不会发送。

推荐配置：跨域认证场景下，将 Cookie 设置为SameSite=None; Secure，且必须通过 HTTPS 传输。

5. 解决方案：三步配置法

5.1 服务端配置（以 Spring Boot 为例）

@RestController@CrossOrigin(origins="https://web.example.com",allowCredentials="true")publicclassApiController{// ...}

或在全局配置中设置：

@ConfigurationpublicclassCorsConfigimplementsWebMvcConfigurer{@OverridepublicvoidaddCorsMappings(CorsRegistryregistry){registry.addMapping("/**").allowedOrigins("https://web.example.com")// 必须具体.allowCredentials(true)// 必须 true.allowedMethods("*");}}

5.2 前端配置（以 Fetch 为例）

fetch('https://api.example.com/user',{method:'GET',credentials:'include',// 关键：告知浏览器携带 Cookieheaders:{'Content-Type':'application/json'}});

5.3 Cookie 自身配置

服务端下发 Cookie 时，必须包含：

Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure; SameSite=None

注意：SameSite=None必须配合Secure，且必须使用 HTTPS 连接。

6. 对比分析：同域 vs 跨域携带条件

7. 最佳实践与安全建议

7.1 严格限制允许的源

• 永远不要使用Access-Control-Allow-Origin: *+allowCredentials: true，浏览器会直接拒绝。
• 仅在必要时开放特定源，避免将敏感 Cookie 暴露给不可信的第三方。

7.2 配合防御措施

• CSRF 防护：即使 Cookie 携带，也应配合SameSite=Lax或 CSRF Token，防止恶意站点利用用户身份发起请求。
• HTTPS 全站：SameSite=None时必须使用 HTTPS，同时确保 Cookie 设置Secure。
• 最小化暴露：Cookie 仅存 Session ID，不存敏感信息。

7.3 开发调试注意事项

• 跨域请求携带 Cookie 时，浏览器会先发送OPTIONS预检请求，确保服务端 CORS 配置正确。
• 本地开发时，可使用localhost或配置代理绕过跨域，但生产环境必须严格遵循规范。

8. 常见误区

9. 总结：一张图看懂跨域携带 Cookie

核心结论：跨域携带 Cookie 不是“自动”的，而是三方显式协商的结果。前端声明携带，后端明确允许，Cookie 自身不阻拦。生产中务必严格控制允许的源，配合 HTTPS 与SameSite，在实现功能的同时守住安全底线。