防止 JWT Token 被 XSS 攻击窃取的最佳方案是将其存储在设置了 HttpOnly 和 Secure 标志的 Cookie 中，而不是 localStorage 或 sessionStorage。这种存储方式禁止 JavaScript 读取 Cookie 内容，适用于大多数 Web 应用，但需配合 HTTPS 传输并注意 CSRF 防护。

快速处理思路

若无法立即重构存储方案，可先实施以下配置降低风险，但长期仍建议迁移至 HttpOnly Cookie。

1. 后端设置 Cookie 响应头：Set-Cookie: token=xxx; HttpOnly; Secure; SameSite=Strict; Path=/

2. 前端移除所有localStorage.setItem或sessionStorage存储 Token 的代码。

3. 强制全站 HTTPS，配置 HSTS 响应头防止降级攻击。

为什么会这样

XSS 攻击的核心是通过注入恶意脚本读取客户端存储数据，而 HttpOnly 属性从浏览器层面禁止了脚本访问 Cookie。

当 JWT 存储在 localStorage 或 sessionStorage 时，任何在同源下执行的 JavaScript 代码（包括恶意注入的脚本）都可以直接读取 Token 并发送给攻击者。HttpOnly Cookie 标记告诉浏览器该 Cookie 只能通过 HTTP 请求发送给服务器，JavaScript 的document.cookieAPI 无法获取其内容，从而切断了 XSS 窃取 Token 的路径。但 Cookie 存储引入了 CSRF 风险，因此需要 SameSite 属性配合防御。

分步处理

1. 修改后端认证接口：在登录成功返回 Token 时，不再将 Token 放在响应体中供前端存储，而是通过 Set-Cookie 头下发。

2. 配置安全属性：确保 Cookie 包含 HttpOnly（防 XSS）、Secure（防中间人窃听）、SameSite=Strict（防 CSRF）。

3. 清理前端代码：搜索项目中所有引用 JWT 变量的地方，移除从 localStorage 读取 Token 并放入 Authorization 头的逻辑，改为依赖浏览器自动携带 Cookie。

4. 配置 CORS：如果前后端分离，设置Access-Control-Allow-Credentials: true，并确保前端请求配置withCredentials: true。

怎么验证是否生效

1. 打开浏览器开发者工具，进入 Application 或 Storage 面板，查看 Cookie 列表。

2. 确认目标 Token 对应的 Cookie 行中，HttpOnly 和 Secure 列显示为选中或 true 状态。

3. 在 Console 面板输入document.cookie，返回的字符串中不应包含该 Token 值。

4. 使用抓包工具（如 Wireshark 或浏览器 Network 面板）确认请求仅在 HTTPS 协议下发送了 Cookie。

常见坑

1. CSRF 风险：使用 Cookie 存储后，若未配置 SameSite 或 CSRF Token，攻击者可能诱导用户浏览器发送请求。建议同时实施 CSRF 双重提交验证。

2. 跨域问题：前后端不同域时，Cookie 默认不发送，需正确配置 Domain 属性和 CORS 凭证模式，否则会导致登录态失效。

3. 令牌大小：JWT 体积通常大于 Session ID，存入 Cookie 需注意 HTTP 头大小限制，避免超出 4KB 导致请求失败。

常见问题

localStorage 存储 JWT 一定不安全吗？

是的，只要存在 XSS 漏洞，localStorage 中的 JWT 就极易被窃取，因为 JavaScript 可随意读取该存储区域。

HttpOnly Cookie 能完全防止 CSRF 吗？

不能，HttpOnly 仅防 XSS，防 CSRF 需依赖 SameSite 属性或额外的 CSRF Token 验证机制。

必须启用 HTTPS 才能用 Secure Cookie 吗？

是的，Secure 标志要求浏览器仅在加密的 HTTPS 连接中发送 Cookie，HTTP 下会被浏览器拦截。

参考来源

• JWT 令牌如何防止被盗用
• Token JWT IO 常见问题：如何安全存储 JWT 避免 XSS 攻击？_编程语言-CSDN 问
• 如何安全存储 JWT:Cookie 与 Web Storage 的深度实践指南
• Token 被抓包截获了怎么办 防御 JWT 泄露的网络安全配置方法