敏感信息不该直接存入 localstorage，因其无访问控制、跨标签页共享且永久驻留磁盘；前端加密无效，密钥易被提取或拦截；应改用 httponly cookie 存凭证，前端仅存非敏感数据。
敏感信息不该直接存入 LocalStorage，因为它根本不是为安全存储设计的。它没有访问隔离、不支持自动过期、无法设 HttpOnly 或 Secure 标志，任何同源脚本（包括 XSS 注入的恶意代码）都能随意读写——相当于把钥匙挂在门把手上。
LocalStorage 的三个硬伤
• 无访问控制：只要页面存在一个 XSS 漏洞，攻击者一行 localStorage.getItem('token') 就能拿走所有凭证；
• 跨标签页共享：用户开十个同源标签页，只要其中任意一个被钓鱼页面攻陷，其他九个页里的 token 全部暴露；
• 永久驻留磁盘：登出后数据不自动清除，用户在网吧、公司电脑上登录一次，下次别人打开浏览器就能复用凭证。
前端加密 ≠ 安全
把 token 用 AES 加密再存进 LocalStorage，听起来很专业，但实际防护效果极弱：
• 密钥若硬编码在 JS 中，攻击者可直接提取；
• 若密钥由服务端动态下发，XSS 脚本也能拦截响应并复用；
• 加密逻辑本身运行在前端，恶意脚本可完整模拟加解密过程，甚至劫持密钥派生流程。
真正该怎么做
• 认证凭据必须走 HttpOnly Cookie：配合 Secure + SameSite=Strict，JS 无法读取，天然防 XSS 窃取；
• 前端只存非敏感标识：比如用户 ID、头像 URL、主题偏好，这些即使泄露也不会导致账户接管；
• 临时敏感数据可用 sessionStorage：关闭标签页即销毁，适合存单次操作所需的短期 token 或表单草稿；
• 关键字段绝不缓存：手机号、身份证、余额等，每次需要时都走后端接口按需获取，不在前端落地。
补救已存在的风险
如果项目里已经用了 LocalStorage 存 token 或用户信息：
• 立即停写新敏感数据；
• 在登出逻辑中调用 localStorage.removeItem('token')；
• 对历史数据做批量清理，可借助版本升级时的迁移脚本触发清除；
• 后续所有认证状态管理交由服务端 Session 或带签名校验的 JWT + HttpOnly Cookie 实现。
