这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
Cookie 与 Header
一个绕不开的问题
Token 设计好了，接下来是「客户端把它放哪」。Web 场景最常见的两个选项：
- Cookie：浏览器自动带上，配合
HttpOnly、Secure、SameSite。 - Authorization Header：前端把 Token 存到内存 / LocalStorage，请求时手动带上。
选错的风险很具体：XSS 会偷走脚本能读到的 Token，CSRF 会让浏览器自动带上不该带的 Cookie。
两条路的威胁模型
Cookie（HttpOnly）
- 用
HttpOnly标记后，脚本读不到 Cookie——这是关键优势，XSS 攻击者拿不到。 - 浏览器会自动带上 Cookie——这又是风险来源：如果目标接口没有防护，攻击者可以诱导用户浏览器发请求，形成 CSRF。
- 缓解 CSRF：
SameSite属性 + 校验来源（Origin/Referer）+ 自定义请求头。
Authorization Header（LocalStorage / 内存）
- Token 由前端显式读取并放到 Header 里——脚本能读到，XSS 一旦得手，Token 直接泄露。
- 但请求不是浏览器自动携带的，天然规避了 CSRF 的自动携带问题。
- 适合 API 调用和移动端（移动端没有 Cookie 概念，通常直接带 Header）。
一张表说清楚
| 维度 | HttpOnly Cookie | Authorization Header |
|---|---|---|
| 防 XSS 窃取 | 强（脚本读不到） | 弱（依赖脚本隔离） |
| CSRF 风险 | 有（需 SameSite + 校验） | 基本无 |
| 适用端 | 浏览器 | API、移动端、纯前后端分离 |
| 额外注意 | SameSite、Domain、Secure | 别用 localStorage 存长期 Refresh Token |
我的选择
- 浏览器端：优先 HttpOnly Cookie。让脚本读不到 Token，把 XSS 风险挡在门外；CSRF 用
SameSite=Lax/Strict+ 校验来源处理。 - 移动端 / 纯 API：用 Authorization Header，重点防 XSS 和本地存储泄露——不要把 Refresh Token 长期放在
localStorage，尽可能放内存或安全存储。
没有绝对安全
关键不是「选哪个」，而是理解你的威胁模型：
- 如果你的系统 XSS 漏洞多，Cookie + HttpOnly 更稳。
- 如果你的系统全是 API / 移动端，Header 更自然。
- 无论哪种，都配合短有效期、可撤销的 Token 体系兜底。
到这里，Token 怎么设计、怎么存，已经完整了。下一章进入会话管理：登录态怎么续期、怎么撤销、多设备怎么处理。
发现内容有问题？
告诉我们哪里需要改进。