JavaScript读写跨域Cookie的限制与SameSite属性

作者：拾光

时间：2026-10-30

深入解析JavaScript在跨域场景下读写Cookie的限制机制，梳理同源与同站边界差异，以及SameSite属性对跨域网络请求Cookie传递的具体控制。

文章目录

在现代浏览器的安全模型下，JavaScript 无法通过 document.cookie 直接读取或篡改任何非同源站点的 Cookie；而在使用 fetch 或 XMLHttpRequest 发起跨域网络请求时，浏览器是否会自动附带或接收 Cookie，则完全取决于 Cookie 的 SameSite 属性设置以及请求上下文的同站判定规则。本文将系统梳理客户端脚本访问 Cookie 的物理边界、同源与同站的核心差异，并逐项解析 SameSite 三种模式的运行机制与排查要点。

一、JavaScript 直接读写 Cookie 的边界与物理限制

许多开发者在遇到跨域协同或多系统集成时，常会产生“能否在前端直接读取另一个域名的 Cookie”的疑问。答案是完全否定的。浏览器基于最根本的同源策略（Same-Origin Policy）对 DOM 接口进行了物理隔离。

在浏览器环境中，通过 document.cookie 操作 Cookie 时受制于两条硬性铁律：

同源作用域限制：页面内执行的 JavaScript 仅能访问归属于当前页面所在源（Origin，由协议、域名、端口共同构成）且路径（Path）匹配的 Cookie。如果当前页面位于 https://app.a.com，前端脚本绝不可能读取到 https://b.com 下存储的任何 Cookie。
HttpOnly 标记阻断：即便是在完全同源的上下文中，只要服务端下发 Cookie 时标记了 HttpOnly，浏览器就会将该 Cookie 标记为“仅网络可用”。此时 document.cookie 将完全对其隐形，既无法读取也无法通过赋值进行修改或删除。这是防范跨站脚本攻击（XSS）窃取会话凭证的最关键防线。

JavaScript读写跨域Cookie的限制与SameSite属性 — 图 1：同源策略与 HttpOnly 对客户端 document.cookie 的访问边界约束

二、认知关键分水岭：同源（Same-Origin）与同站（Same-Site）

在理解跨域网络请求中的 Cookie 规则之前，必须厘清“同源”与“同站”的概念差异。很多开发者会误把二者混为一谈，从而导致配置错误。

同源（Same-Origin）：要求“协议（Protocol）+ 域名（Domain/Host）+ 端口（Port）”三者完全一致。任何一项不同，在安全策略中即判定为跨域（Cross-Origin）。例如 https://app.example.com 与 https://api.example.com 属于不同源。

同站（Same-Site）：根据公共后缀列表（Public Suffix List, 如 .com、.org、.com.cn 等）判定。只要顶级域名与二级域名结合后的有效顶级域名加一（eTLD+1）一致，即属于同站。此外，现代浏览器实行 Schemeful Same-Site，协议也必须匹配才算完全同站。

基准页面 A	请求目标 B	同源判定 (Same-Origin)	同站判定 (Same-Site)
`https://example.com`	`https://example.com/api`	同源 (Same-Origin)	同站 (Same-Site)
`https://app.example.com`	`https://api.example.com`	跨域 (Cross-Origin)	同站 (Same-Site)
`http://example.com`	`https://example.com`	跨域 (协议不同)	跨站 (Schemeful 规则)
`https://example.com`	`https://otherdomain.com`	跨域 (不同源)	跨站 (Cross-Site)

三、网络请求中的 Cookie 传递与 SameSite 属性控制

虽然脚本不能跨域读取 Cookie，但在前端通过 fetch 或 XMLHttpRequest 请求远程 API 时，浏览器在网络传输层是否附带该远程站点的已存 Cookie？决定这一行为的核心属性正是 SameSite。

SameSite 属性用于声明 Cookie 是否限制在第一方上下文（当前在地址栏显示的站点）中传输。它拥有三个可选值：

1. SameSite=Strict

最为严格的模式。在该模式下，Cookie 绝不会在任何跨站请求中被发送。哪怕用户从外部搜索引擎（如从 google.com 点击链接跳转进入 example.com），初次进入时也不会携带该 Cookie，直到用户在站内发起后续请求。此配置适合对安全性要求极高、完全不依赖外部引流自动保持登录态的敏感系统。

2. SameSite=Lax（现代浏览器默认值）

为了在安全性与用户体验之间取得平衡，主流浏览器（如 Chrome 80+）将未显式声明 SameSite 的 Cookie 默认视为 Lax。在 Lax 模式下：

普通跨站请求（如页面发起的跨站 POST 请求、跨站 fetch、<iframe> 内嵌页面请求、<img> 图片引用）均不会携带 Cookie。这有效消除了传统跨站请求伪造（CSRF）的主要漏洞。
仅在顶级导航（Top-level Navigation）且属于安全方法（如普通 <a href> 链接点击或 GET 表单提交）跳转时，才会携带该 Cookie。

3. SameSite=None

允许在所有跨站上下文中附带 Cookie，包括内嵌 iframe 与跨站异步 API 请求。但浏览器做出了强制安全限制：

强制约束：声明 SameSite=None 时，必须同时声明 Secure 属性，即必须在 HTTPS 协议下传输；否则浏览器将直接拒绝写入该 Cookie。

四、让跨域请求合法携带 Cookie 的完整工程配置

如果业务架构确实需要跨站点调用 API 且必须依赖 Cookie（例如基于会话 Cookie 的单点鉴权），客户端与服务端必须协同完成如下三项配置：

1. 服务端设置 Cookie 属性

服务端下发 Set-Cookie 响应头时，必须显式附加 SameSite=None; Secure：

Set-Cookie: session_id=abc123456; Path=/; Domain=.api-service.com; SameSite=None; Secure; HttpOnly

2. 客户端发起请求声明凭据模式

在原生 fetch 中，必须将 credentials 设置为 'include'；在 Axios 中，则对应 withCredentials: true：

// 原生 fetch 示例
fetch("https://api-service.com/user/profile", {
  method: "GET",
  credentials: "include" // 关键：指示浏览器发送并接收跨域 Cookie
})
.then(response => response.json())
.then(data => console.log("请求成功", data));

3. 服务端开放严格的 CORS 响应头

携带凭据的跨域请求对 CORS 响应头有严苛要求，通配符 * 会直接导致浏览器报错：

Access-Control-Allow-Origin：必须是具体的发起方域名（如 https://app.client.com），绝对不能使用 *。
Access-Control-Allow-Credentials：必须明确设置为 true。

五、跨域排查步骤与体系全景总结

在开发与集成联调过程中，若发现跨域请求未附带预期的 Cookie，可按以下标准步骤逐一排查：

检查传输协议：目标接口是否为 HTTPS。若处于 HTTP 环境，SameSite=None; Secure 会被浏览器直接丢弃。
检查浏览器控制台 Network 面板：展开对应请求的 Cookies 选项卡，查看是否有黄色感叹号。浏览器会在该面板明确标注阻断原因（如“此 Cookie 因 SameSite=Lax 策略被拦截”）。
检查服务端 CORS 头：确保响应头包含 Access-Control-Allow-Credentials: true 且 Access-Control-Allow-Origin 与当前页面 Origin 严格匹配。
跨站跟踪防护（第三方 Cookie 淘汰）：现代浏览器正在逐步默认禁用第三方 Cookie。对于全新的架构设计，推荐使用基于 HTTP Authorization 头传递 Bearer Token 的方式代替隐式 Cookie 传递。