不建议将 JWT 存储在 LocalStorage，因为 JavaScript 可随意读取，一旦存在 XSS 漏洞令牌即刻泄露。生产环境推荐优先使用 HttpOnly Cookie 存储敏感认证令牌，配合 Secure 和 SameSite 属性，从浏览器层面阻断脚本访问。

快速处理思路

若项目正在使用 LocalStorage 存 Token，需评估 XSS 防护能力。若无法确保零 XSS 风险，应迁移至 HttpOnly Cookie 方案。

1. 后端修改登录接口，将 Token 写入 HttpOnly Cookie 而非返回给前端存储。
2. 前端移除 localStorage.setItem 逻辑，请求时依赖浏览器自动携带 Cookie。
3. 配置 CSRF 防护，如开启 Cookie 的 SameSite 属性或配合 CSRF Token。

为什么会这样

LocalStorage 的设计允许 JavaScript 自由读写，这意味着任何能执行脚本的漏洞都能窃取数据。

当网站存在跨站脚本攻击（XSS）漏洞时，攻击者注入的恶意脚本可以直接调用 localStorage.getItem 获取 JWT 令牌并发送至远程服务器。相比之下，HttpOnly Cookie 被浏览器标记为禁止 JavaScript 访问，即使页面被注入脚本，document.cookie 也无法读取到该字段，从根源上切断了脚本窃取令牌的路径。

分步处理

实施 HttpOnly Cookie 存储需要前后端配合，重点在于后端设置标志位和前端请求配置。

1. 后端设置 Cookie 属性

在登录响应头中设置 Set-Cookie，必须包含 HttpOnly 和 Secure。

Set-Cookie: token=eyJ...; HttpOnly; Secure; SameSite=Strict; Path=/

2. 前端请求配置

使用 Axios 或 Fetch 时，需开启凭据发送，否则浏览器不会自动携带 Cookie。

axios.post('/api/login', data, { withCredentials: true })

3. 清理旧存储

迁移完成后，务必清除前端代码中所有读取 localStorage 中 Token 的逻辑，避免残留代码导致混淆。

怎么验证是否生效

通过浏览器开发者工具检查 Cookie 属性和 JavaScript 访问权限。

1. 打开开发者工具，进入 Application 或 Storage 面板，查看 Cookies 列表。
2. 确认目标 Token 对应的 HttpOnly 列已被勾选。
3. 在 Console 面板输入 document.cookie，检查返回字符串中是否包含该 Token，若不包含则防护生效。

常见坑

• CSRF 风险：Cookie 会自动随请求发送，需配合 SameSite 属性或 CSRF Token 防止跨站请求伪造。
• 跨域问题：前后端分离时，若域名不同，需正确配置 Cookie 的 Domain 属性及 CORS 凭据。
• HTTPS 要求：设置了 Secure 属性的 Cookie 仅在 HTTPS 协议下传输，本地开发需注意协议匹配。

常见问题

LocalStorage 完全不能用吗？

非敏感数据可以使用。LocalStorage 适合存储主题配置、缓存数据等公开信息，但严禁存储认证令牌。

HttpOnly Cookie 如何防止 CSRF？

需设置 SameSite 属性为 Strict 或 Lax，或在请求头中额外携带 CSRF Token 进行二次验证。

刷新页面后 Token 会丢失吗？

不会。Cookie 可设置过期时间，持久化存储在服务端指定的有效期内，刷新页面后浏览器会自动保留。

参考来源

• 前端圈集体踩坑:localStorage 存 JWT
• jwt 存 localstorage 有什么风险
• 如何安全储存 JWT 之 Cookie 与 Web Storage
• 客户端 jwt 存储在 localStorage 与 cookie 有什么区别
• JWT 登录后，前端应将 token 存储在 localStorage 还是 cookie 中？
• JWT 在浏览器中的存储策略
• JWT 令牌安全存储实战指南:HttpOnly Cookie 与内存存储的 XSS 防护效果深度对比
• 为什么你的 Token 不该由前端存储？—— 深入理解 HttpOnly Cookie 与前端 Cookie 的安全差异