一篇读懂 Cookie 与 Session：无状态 HTTP 的记忆术

问题的起点：HTTP 的失忆症

HTTP 协议的每个请求都是独立的：服务器处理完就忘。但「登录状态」需要记忆——不然每个页面都要重新输密码。Cookie 是浏览器的记忆机制：服务器通过响应头 Set-Cookie 让浏览器存一小段数据，之后浏览器每次请求同一站点时自动带上（Cookie 头）——服务器靠这段数据认出「这是刚才那个用户」。Session 是服务器的记忆机制：Cookie 里通常只存一个不透明的会话 ID（如 sessionId=abc123），真正的会话数据（用户 ID、权限、过期时间）存在服务器内存或 Redis 里——浏览器只带钥匙，服务器拿钥匙开自己的柜子。

Cookie 的五个属性：每一项都是安全开关

Cookie 的行为由属性精细控制，每个属性都是一扇安全门。Domain：Cookie 归属的域名（默认当前域，可设父域实现子域共享）——Domain 越宽风险越大（父域 Cookie 被任何子域读取，一个被攻破的子域连累全部）。Path：路径范围（默认 / 全站）。Expires/Max-Age：寿命——不设是会话 Cookie（关浏览器就没了），设了是持久 Cookie。Secure：只在 HTTPS 连接发送（防明文嗅探，现代标配）。HttpOnly：禁止 JavaScript 读取（document.cookie 拿不到）——XSS 防线的关键：即使页面被注入恶意脚本，脚本也偷不走会话 Cookie。SameSite：跨站请求是否携带——Strict（完全不带）、Lax（默认；顶级导航 GET 带其他不带）、None（总是带，需配合 Secure）——CSRF 防线的核心（下节展开）。

Session vs Token：两代认证架构

Session-Cookie 模式（经典）：服务器存会话状态、Cookie 带会话 ID。优点：服务端可随时踢人（删会话即下线）、可控性强。缺点：服务器有状态（多实例要共享会话存储——Redis 集群）、跨域与移动端不便。Token 模式（JWT 为代表）：把会话数据签名后直接发给客户端（JWT = 头.载荷.签名），客户端每次请求带上，服务器只验签名不查库。优点：无状态（服务器不存会话，水平扩展天然）、跨服务友好（签名验证即可）。缺点：无法主动作废（签出去的 token 到期前一直有效——「踢人」要靠黑名单机制，但黑名单又把无状态改回有状态）、载荷可被解码查看（JWT 只是签名不是加密——别把敏感数据放载荷里）。选型的粗规则：传统 Web 应用与需要强踢人能力的选 Session；分布式微服务、移动端、跨域场景选 JWT（配短过期时间 + Refresh Token 轮换）。

两个攻击面：XSS 偷 Cookie 与 CSRF 用 Cookie

XSS 偷 Cookie：页面被注入恶意脚本 → 脚本读 document.cookie → 发给攻击者。防线：HttpOnly（脚本读不到）+ 输入输出转义（不让脚本进来）+ CSP（限制脚本能发数据到哪）。CSRF（跨站请求伪造）：你登录着银行 A，同时开着恶意网页 B——B 里的隐藏表单自动向 A 发起请求，浏览器带着 A 的 Cookie 去了（浏览器自动附带同站 Cookie 的特性被武器化），A 分不清「这是用户点的还是 B 伪造的」。防线是 SameSite：SameSite=Lax/Strict 下跨站请求不带 Cookie——伪造请求变成了「没带钥匙的陌生人」。同源策略与 SameSite 的组合是浏览器的默认护城河（这就是为什么现代框架的 CSRF Token 渐成纵深防御的第二层而非唯一防线）。

第三种攻击：子域与父域的信任传导。Cookie 的 Domain 设宽（.example.com）后，任何一个子域（比如某个年久失修的营销子站）都能设置/读取主站 Cookie——子域被黑 = 主站会话被劫持。大厂的「Cookie 隔离」（关键会话用窄 Domain + 独立域名）就是把信任传导切干净。

认证架构的进阶：Refresh Token、SSO 与第三方登录

Cookie/Session 与 Token（正文）之上，现代认证还有三个进阶构件。构件一：Refresh Token 机制。JWT 的「无法作废」用双 Token 化解：Access Token 短命（15 分钟，泄露了危害窗口小）+ Refresh Token 长命（存 HttpOnly Cookie，仅用于换新 Access Token）——刷新时轮换 Refresh Token（旧的作废，被盗用的旧 Token 在下次刷新时暴露）。构件二：SSO（单点登录）。一套登录态跨多个系统共享——企业内部 SSO（OIDC 协议，本库 Agent 生态篇的认证基建与之呼应）的体验与安全设计：中央认证服务的会话 + 各应用的「 ticket 换会话」。构件三：第三方登录（OAuth 的正确理解）。「用微信/GitHub 登录」的底层是 OAuth 授权——OAuth 不是认证协议（它是「授权第三方访问你的资源」），OIDC 才是在它之上的认证层——理解这个区分能解释「为什么登录流程里要有那么多跳转与 code 交换」（授权码模式的防泄漏设计：code 短命单次、后端换 token，避免 token 出现在前端 URL）。三个构件合成的现代认证全景：Refresh 管时效、SSO 管共享、OAuth/OIDC 管联邦——Cookie/Session（正文）仍是它们脚下的地基，浏览器侧的每一次「登录态」，最终都落在某个 Cookie 的某个属性配置上。

认证的实战排查：登录态问题的四象限

认证问题的排查可以按「服务端状态 vs 客户端状态」分四象限，常见的登录态 bug 各有归属。象限一：客户端有 Cookie、服务端会话还在，但不工作——大概率是「属性错配」：Domain 设错（子域没共享到）、Path 限制、SameSite 把跨站的 XHR 排除了（前后端分离部署在不同域时的经典事故——解法是同站部署或正确配置 CORS + SameSite=None + Secure）。象限二：Cookie 带了、服务端说没会话——服务端会话存储问题（Redis 重启丢了、多实例间没共享——负载均衡轮询到没有该会话的实例）、或时钟漂移（JWT 的 exp 校验、服务器时间不同步）。象限三：登录成功但马上又要求登录——Cookie 没写成功（Secure 属性在 HTTP 环境下被浏览器拒绝！开发环境 HTTP + Secure=true 的经典事故）或 Set-Cookie 被同源策略/浏览器策略拦截。象限四：间歇性掉登录——Session 的过期与滑动续期配置、JWT 的 Refresh 逻辑竞态（两个请求同时用旧 Refresh Token 刷新——一个成功一个 401，需要轮换锁）。排查的元方法：开发者工具的 Network 面板逐请求看「Cookie 头有没有带、Set-Cookie 有没有回、带了什么属性」——登录态问题的九成，答案都写在这两个头里。

Cookie 的现代替代者：Token 存储的三种姿势与权衡

Cookie/Session（正文）的现代语境里，JWT 时代带来一个新问题：Token 到底存在客户端哪里——三种姿势的权衡是前后端安全的高频考题。姿势一：LocalStorage。方便（JS 直接读写）、但 XSS 可偷（脚本可读——等于把会话钥匙挂在门上，一旦有 XSS 就全丢）——「简单但不安全」的代表。姿势二：内存（JS 变量）。最安全（脚本偷不走刷新也没了）——代价是刷新即失（用 Refresh Token 重取，或接受频繁重新认证）——「最安全但不便」的代表。姿势三：HttpOnly Cookie。JS 读不到、自动携带——但引入 CSRF 面（要配 SameSite）与跨域复杂度（前后端分离的域策略）。行业共识的收敛：Access Token 放内存（短命）、Refresh Token 放 HttpOnly+Secure+SameSite=Strict Cookie——两全的组合（偷不到、丢了也丢小的）。这个议题的元意义：它展示了 Web 安全的经典三角——便利性、攻击面、复杂度——三个角上不可能同时赢，选型就是把「最怕的那种攻击」的防线建在代价最小的位置。Cookie（三十岁的技术）在 Token 时代仍是答案的一部分——因为浏览器的安全模型（HttpOnly/SameSite）恰恰是 Cookie 的属性在撑着。

认证架构的进阶：Refresh Token、SSO 与第三方登录

Cookie/Session 与 Token（正文）之上，现代认证还有三个进阶构件。构件一：Refresh Token 机制。JWT 的「无法作废」用双 Token 化解：Access Token 短命（15 分钟，泄露了危害窗口小）+ Refresh Token 长命（存 HttpOnly Cookie，仅用于换新 Access Token）——刷新时轮换 Refresh Token（旧的作废，被盗用的旧 Token 在下次刷新时暴露）。构件二：SSO（单点登录）。一套登录态跨多个系统共享——企业内部 SSO（OIDC 协议，本库 Agent 生态篇的认证基建与之呼应）的体验与安全设计：中央认证服务的会话 + 各应用的「 ticket 换会话」。构件三：第三方登录（OAuth 的正确理解）。「用微信/GitHub 登录」的底层是 OAuth 授权——OAuth 不是认证协议（它是「授权第三方访问你的资源」），OIDC 才是在它之上的认证层——理解这个区分能解释「为什么登录流程里要有那么多跳转与 code 交换」（授权码模式的防泄漏设计：code 短命单次、后端换 token，避免 token 出现在前端 URL）。三个构件合成的现代认证全景：Refresh 管时效、SSO 管共享、OAuth/OIDC 管联邦——Cookie/Session（正文）仍是它们脚下的地基，浏览器侧的每一次「登录态」，最终都落在某个 Cookie 的某个属性配置上。

认证的安全基线：一张上线前的检查单

认证与 Cookie/Session（正文）的上线前安全基线，一页检查单。会话层：会话 ID 足够随机（不递增不预测）、登录后重置会话 ID（防会话固定攻击）、登出即失效（服务端删除而非仅清 Cookie）、超时有配置且合理。Cookie 层：HttpOnly + Secure + SameSite 三件套齐全、Domain 尽量窄（不随意设父域）、敏感 Cookie 不设过长寿命。密码层：存储用 bcrypt/argon2（禁明文禁 MD5）、有防暴力（限流 + 锁定）、找回流程不泄露「账号是否存在」（统一响应文案）。传输层：全站 HTTPS（认证页与登录后页面同等）、HSTS 开启。日志层：登录成功/失败有记录（异常 IP 告警）、日志里绝不打印密码与完整 token。检查单的用法：新项目上线前逐项打勾、存量项目按缺补齐——认证安全的事故清单（撞库、会话劫持、token 泄露）几乎都能被这一页拦住大半——安全基线的价值不在高深，在「每一条都真的做了」。

小结

无状态 HTTP 的记忆由两层构成：Cookie（浏览器侧的记忆与自动携带）与 Session（服务器侧的状态存储），Cookie 里通常只有会话 ID。Cookie 五属性全是安全开关：Domain/Path 控范围、Expires 控寿命、Secure 防嗅探、HttpOnly 防 XSS 偷取、SameSite 防 CSRF。认证架构两代：Session 有状态可踢人、JWT 无状态易扩展但难作废（短有效期 + Refresh 轮换补救）。两大攻击面：XSS 偷 Cookie（HttpOnly 防线）、CSRF 用 Cookie（SameSite 防线）；父域 Cookie 的信任传导是大企业的隐性风险。Cookie 是互联网最古老的「用户身份」技术——三十年来它的每次属性更新，都是一次攻击与防御的军备竞赛成果。