P56 项目场景面试：用户登录 Token 存储的安全漏洞
面试题：登录后的 Token 存在哪里才安全？LocalStorage、SessionStorage、Cookie 各有什么安全漏洞？
1. 先说结论
- LocalStorage/SessionStorage 存 Token 不安全：任何脚本（尤其是 XSS 注入的脚本）都能直接读取；
- Cookie 也有风险：设置不当（无 HttpOnly、无 Secure、无 SameSite）会被窃取或用于 CSRF；
- 安全做法：HttpOnly + Secure + SameSite Cookie，或 Token 存内存/安全存储，配合短有效期 + 刷新机制。
2. 各方案对比
| 存储位置 | 风险 | 说明 |
|---|---|---|
| LocalStorage | XSS 可读 | JS 能直接 localStorage.getItem('token')，一旦 XSS 就泄露；且持久存在 |
| SessionStorage | XSS 可读 | 同上，但关标签页即失效，风险稍低 |
| Cookie（无 HttpOnly） | XSS 可读 + CSRF 风险 | JS 可读 Cookie，跨站请求会自动携带 |
| Cookie（HttpOnly） | 防 XSS 读取，仍有 CSRF 风险 | JS 读不到，但请求自动带 Cookie |
| 内存（JS 变量） | XSS 仍可能读，刷新丢失 | 最接近"不落地"，但要处理刷新后的会话 |
3. 核心漏洞与攻击
① XSS（跨站脚本）— Token 泄露主因
攻击者在页面注入脚本 → 读取 LocalStorage 里的 Token → 把 Token 发到攻击者服务器 → 冒充用户。
防御：
- 输入输出转义/过滤，CSP 限制脚本来源；
- 敏感接口用 Token 而不是长期 Cookie；
- Token 不落 LocalStorage。
② CSRF（跨站请求伪造）— Cookie 自动携带
攻击者诱导用户访问恶意页面，浏览器自动携带 Cookie 发起请求。
防御：
- Cookie 加
SameSite=Strict/Lax； - 关键操作校验自定义 Header/二次确认；
- 用 Authorization Header 传 Token（不自动携带，天然防 CSRF）。
4. 生产推荐方案
text
短期 AccessToken（15 分钟~2 小时，HttpOnly Cookie 或内存）
+ 长期 RefreshToken（服务端存，可吊销）
+ SameSite=Strict + Secure
+ XSS 防护（CSP、转义）+ CSRF Token/Header 校验5. 加分点
- 主动提出"Access Token 短 + Refresh Token 长"的双 Token 模型；
- 提 Token 吊销（服务端 Session/Redis 黑名单）；
- 登录设备管理、异地登录提醒；
- 面试官如果问"那用 Cookie 还是 Header"：可以答"HttpOnly Cookie 防 XSS + 自定义 Header/CSRF Token 防 CSRF，两者配合"。
一句话总结
Token 存 LocalStorage 会被 XSS 直接偷走，Cookie 自动携带带来 CSRF 风险；安全方案是 HttpOnly+Secure+SameSite 的 Cookie 或内存存储，配合短 AccessToken + 可吊销 RefreshToken + XSS/CSRF 双重防御。