Cookie存Token会引发XSS窃取（HttpOnly=false时）、CSRF滥用（SameSite未配置）、日志泄露、服务端无法强制失效等问题，必须配合HttpOnly+Secure+SameSite、加密签名、双端过期校验及后端状态管理。
Cookie 存 Token 会引发哪些实际问题
不是“能不能存”，而是“存了之后谁来保安全、谁来控生命周期、谁来防篡改”。直接把 access_token 或 refresh_token 明文塞进 Cookie，等于把钥匙贴在门上还留了张纸条写“请勿偷看”。
- 浏览器 DevTools 里右键“Copy as cURL”就能拿到完整 token，XSS 攻击下几乎零成本窃取
-
HttpOnly: false时 JS 可读，前端随手document.cookie就暴露；设成true后又没法用 JS 刷新或登出，必须走后端接口 - Cookie 默认随所有同域请求发出（包括图片、iframe、第三方脚本），token 被无意带到非预期端点，日志或监控系统可能意外留存
- 如果没配
SameSite=Lax或Strict，CSRF 攻击可伪造 POST 请求携带该 Cookie，服务端无法区分是用户主动操作还是恶意诱导
对比：Cookie vs Header vs LocalStorage 存 Token 的硬约束
选型不是看“哪个更方便”，而是看“哪个能守住你最不敢丢的东西”——比如用户身份不可冒用、token 不可重放、登出即失效。
-
Cookie：适合需要自动携带、服务端强管控的场景（如登录态维持），但必须配
HttpOnly=true、Secure=true（生产）、SameSite=Lax，且 token 本身应加密或签名（不能裸存） -
Authorization Header：前端需手动在每个请求加
Bearer xxx，不自动携带，XSS 下仍可能被 JS 读取，但至少不参与 CSRF 请求；适合 SPA + API 分离架构 -
LocalStorage：JS 全权限读写，XSS 一击即溃；没有过期机制，无法被服务端强制失效；
localStorage.setItem("token", raw)是目前最常见也最危险的写法
为什么 Echo 中用 Cookie 存 Token 必须搭配加密/签名
因为 c.SetCookie() 写进去的是纯字节流，浏览器不校验、不加密、不防篡改。攻击者改一个字符、延长有效期、伪造 user_id，服务端若只做 if cookie != "" 就放行，等于开门揖盗。
- 别自己拼
"user_id:exp:signature"字符串——时间格式、分隔符、哈希算法稍有偏差就解不出 - 用
gorilla/securecookie实例管理：它内置 HMAC 签名 + 可选 AES 加密，Encode("session", data, &dst)后写入 Cookie，Decode("session", cookieValue, &dst)时自动验签+解密 - 务必检查
err != nil：解密失败、签名不匹配、过期字段被篡改，都会返回错误；忽略它会导致空结构体或默认值，误判为合法登录 - 过期时间必须双端一致：写入时用
time.Now().Add(24 * time.Hour)，解码后还要比对结构体里的ExpiresAt字段，不能信 Cookie 原始Max-Age
真正影响选型的不是技术，是登出与失效策略
如果你的系统要求“用户点退出登录，当前设备 token 立即失效”，那 Cookie 存加密 token 是可行的；但若要支持“踢掉所有设备”或“某次登录异常后批量作废”，就必须把 token 状态落库（PostgreSQL）或 Redis 黑名单，此时 Cookie 只能存轻量 ID，真实凭证放服务端。
- 存完整 token 在 Cookie → 登出只能删本地 Cookie，服务端无感知，旧 token 仍可被重放
- Cookie 只存
session_id→ 登出时删 DB 记录 + 清 Redis key，所有端同步失效 - refresh_token 绝对不能只靠 Cookie Max-Age 控制；它必须带指纹绑定（IP/UA）、单次使用、或滚动更新后立即作废旧值，否则刷新接口就是个永动机
