进安全与边界阶段。HTTP 本身是无状态的——每个请求都是独立的，服务器记不住「你上一个请求是谁」。但 Web 应用需要状态：登录后要记住你是谁，购物车要记住你加了什么。Cookie 就是给无状态 HTTP 加上「记忆」的方案。

Cookie 的基本机制：种、存、带

Cookie 的生命周期分三步：

Cookie 的生命周期：服务器种、浏览器存、请求自动带

  1. 服务器种 Cookie：响应头里带 Set-Cookie: sessionId=abc123; ...，告诉浏览器「存一个 Cookie」。
  2. 浏览器存：浏览器把 Cookie 存起来（按域名归类）。
  3. 请求自动带：之后浏览器对这个域名的每个请求，都会自动带上 Cookie: sessionId=abc123。

关键点是「自动带」——浏览器不需要应用代码干预，只要 Cookie 还在、作用域匹配，每个请求都会带。这就是登录状态能保持的原因：登录时服务器种了 sessionId Cookie，之后每个请求浏览器自动带上，服务器据此识别你。

一个响应可以种多个 Cookie（多个 Set-Cookie 头）。一个域名下可以有多个 Cookie，浏览器请求时把它们用分号拼成一行发出去。

Cookie 的属性：不止是键值对

Cookie 不只是 name=value，它有一组属性控制行为和作用域：

Cookie 的核心属性

  • Domain 和 Path：作用域。Domain=rubyfun.cn 表示这个 Cookie 对 rubyfun.cn 及其子域名有效；Path=/ 表示对这个路径下所有请求有效。作用域决定「哪些请求会带这个 Cookie」。
  • Max-Age 和 Expires：有效期。Max-Age=3600 表示 3600 秒后过期；Expires 是绝对过期时间。两个都没有就是 Session Cookie——关闭浏览器就没了。
  • HttpOnly：禁止 JavaScript 访问这个 Cookie（document.cookie 读不到）。防 XSS 偷 Cookie。
  • Secure：只在 HTTPS 下发送这个 Cookie。防止明文 HTTP 泄露。
  • SameSite：控制跨站请求是否带 Cookie。防 CSRF。

这几个属性里，HttpOnly、Secure、SameSite 是安全相关的，值得单独讲。

三个安全属性：HttpOnly、Secure、SameSite

HttpOnly：防 XSS 偷 Cookie

如果 Cookie 没设 HttpOnly，JavaScript 可以通过 document.cookie 读取它。一旦页面有 XSS 漏洞（攻击者注入了恶意脚本），脚本就能把 Cookie 偷走，冒充用户身份。设了 HttpOnly 后，JavaScript 读不到这个 Cookie，只有浏览器在发请求时自动带——即使有 XSS，Cookie 也偷不走。

会话 Cookie（sessionId）一定要设 HttpOnly。这是基本的安全卫生。

Secure：防明文泄露

没设 Secure 的 Cookie，会在 HTTP 和 HTTPS 下都发送。如果用户不小心用 HTTP 访问，Cookie 在明文传输中被截获。设了 Secure，只在 HTTPS 下发送，HTTP 不带。

SameSite：防 CSRF

SameSite 控制「跨站请求是否带 Cookie」，是防 CSRF 的关键：

  • SameSite=Strict：跨站请求完全不带 Cookie。最严格，但体验有损——从别的网站点链接过来，Cookie 不带，等于没登录。
  • SameSite=Lax：跨站导航（点链接、GET 请求）带 Cookie，但跨站 POST、iframe 等不带。从 Chrome 80（2020 年）起成为默认值（之前默认是 None），平衡了安全和体验。这个默认值的变更直接让大量依赖跨站 Cookie 的老站点踩坑——升级时要注意。
  • SameSite=None：跨站请求都带 Cookie。必须配合 Secure（HTTPS）才能用。

CSRF（跨站请求伪造）的原理就是：攻击者诱导用户在已登录状态下访问恶意页面，恶意页面发跨站请求，浏览器自动带上用户的 Cookie，服务器以为是用户本人操作。SameSite=Lax 默认让跨站 POST 不带 Cookie，直接挡住了大部分 CSRF。

Cookie vs Token：现代认证的取舍

Cookie 不是唯一的会话方案，还有 Token（如 JWT）。两者的核心区别：

Cookie vs Token 的取舍

  • Cookie：浏览器自动带，适合传统 Web 应用（服务端渲染）。但要防 CSRF（因为自动带，跨站也会带）。
  • Token（放 Authorization 头）：应用代码手动带，适合 SPA 和 API。不自动带，所以天然防 CSRF，但要手动管理存储和刷新。

两者不是对立的，很多系统混合用：Cookie 存 sessionId 管传统页面，Token 管 API 调用。关键是理解「自动带」是 Cookie 的特性，既是便利也是风险来源。

取舍与边界

Cookie 有几个值得注意的边界：

  • Cookie 大小有限。单个 Cookie 约 4KB，一个域名约 50 个。别拿 Cookie 存大数据。
  • Cookie 影响性能。每个请求都带 Cookie，如果 Cookie 很多很大，每个请求都增加开销。静态资源用独立域名（Cookieless Domain）能避免这个。
  • 第三方 Cookie 正在被淘汰。跨站追踪用的第三方 Cookie（广告行业依赖）被各浏览器陆续默认屏蔽，这是隐私保护的转向。

收束：Cookie 是 HTTP 的状态层

HTTP 无状态，Cookie 给它加了状态。但「自动带」这个特性既是便利（不用应用代码管），也是风险来源（CSRF）。HttpOnly、Secure、SameSite 三个安全属性，就是针对 Cookie 的三大风险（XSS、明文泄露、CSRF）设计的防线。

下一篇讲 CORS——跨域请求为什么会被浏览器拦？Cookie 和 CORS 经常一起出现，理解了 Cookie 的作用域，CORS 就好理解了。

关于十三Tech

我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。

我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。

如果你想继续跟完这套「图解 HTTP」，欢迎关注公众号 「十三Tech」。后续会按 URL 与报文、连接与传输、缓存与协商、安全与边界、HTTP/2 与 HTTP/3 这条线更新。

十三Tech公众号二维码