应优先使用 HttpOnly Cookie 存储 Token，因其可防 XSS 窃取；若必须用 localStorage，则加密仅为防物理接触泄露，需动态获取密钥、用 Web Crypto API 加密最小必要字段，并避免存储密钥或主 Token。

localStorage 加密不能解决核心问题

把加密后的 Token 直接放进 localStorage，看起来像多了一层保护，但核心问题并没有变化。

一旦发生 XSS，页面里的脚本仍然可以随意读取 localStorage。所谓加密，只是把明文换成了密文。

只要攻击者已经拿到页面控制权，拿到密文之后，要么现场用同一套密钥解开，要么直接把整套加解密逻辑一并搬走。

真正靠谱的思路，不是给 localStorage 再套一层“外壳”，而是尽量降低对它的依赖，同时配合更底层的安全防护机制。

优先改用 HttpOnly Cookie 存 Token

这是目前最成熟、被广泛验证的安全方案。

• 服务端登录成功后，通过 Set-Cookie 响应头下发 Token，带上 HttpOnly、Secure 和 SameSite=Strict（或 Lax）属性
• 浏览器自动在每次同源请求中携带该 Cookie，前端 JS 完全无法读取或篡改
• 即使页面存在 XSS 漏洞，恶意脚本也无法窃取 Token
• 配合后端校验签名、设置短期有效期、支持主动登出失效，形成完整闭环

如果必须用 localStorage，加密只是辅助

加密不是核心防线，它的作用不是防 XSS，而是防本地物理接触泄露。

例如，他人直接打开开发者工具复制值，或浏览器导出数据时发生二次泄露。这种场景下，加密才有一定辅助价值。

关键要配合以下三点：

• 加密密钥不硬编码在代码里，而是从服务端动态获取（如登录后返回一个 session-bound key），且仅缓存在内存中，不用 localStorage 存
• 使用 Web Crypto API 而非第三方库（如 CryptoJS），避免引入不可信的依赖和潜在漏洞
• 加密后只存最小必要字段：例如仅加密用户 ID + 时间戳签名，而非整个 JWT；Token 本身仍由后端签发并校验，前端不信任其内容

用 sessionStorage 替代 localStorage 存短期凭证

对登录态这类会话级数据，sessionStorage 是更合理的选择。

• 关闭标签页即自动清空，天然降低长期泄露风险
• 同样支持加密存储，但生命周期可控，无需手动清理
• 可封装为带自动过期检查的工具：

const safeSessionStore = {
set(key, value, expireInMs = 30 * 60 * 1000) {
const item = {
data: encrypt(value),
expires: Date.now() + expireInMs
};
sessionStorage.setItem(key, JSON.stringify(item));
},
get(key) {
const item = sessionStorage.getItem(key);
if (!item) return null;
const parsed = JSON.parse(item);
if (Date.now() > parsed.expires) {
sessionStorage.removeItem(key);
return null;
}
return decrypt(parsed.data);
}
};

密钥、私钥、主 Token 不要放进 localStorage

无论如何都不要以明文，甚至“加密后”的形式，把密钥、私钥、主 Token 放进 localStorage。

原因很直接：哪怕用了 AES-256，只要解密所需的信息还在前端代码里，或者运行时出现在内存中，调试器、console、堆快照，甚至恶意浏览器扩展，都有机会把它抓出来。

规范的密钥管理，应该完全放在服务端完成。前端负责的，只是传递已经签名的临时凭证，最终的鉴权仍然要由服务端兜底。

《夸克》非常好用的免费AI浏览器

下载APP查看