Web Storage 存储敏感数据必须用 Web Crypto API 的 AES-GCM 加密，密钥须口令派生或临时生成且不落地，IV 随机12字节，加密后结构化 Base64 编码；原始密码、JWT、API 密钥等绝不应存入。

Web Storage（localStorage/sessionStorage）本身不加密、不设防，存进去就是明文，只要页面存在 XSS 漏洞，攻击者一行 localStorage.getItem('token') 就能拿走所有数据。安全不是“要不要加密”，而是“怎么存才不会白加”——密钥管理、算法选型、存储结构、数据边界，四者必须同时到位。

加密必须用 Web Crypto API + AES-GCM

别用 crypto-js 等纯 JS 库：性能差、易逆向、默认 CBC 模式不带完整性校验，防不了篡改。浏览器原生 Web Crypto API 才是正解：

• 必须用 AES-GCM：一次完成加密 + 认证，避免手动拼接 IV 和 MAC 导致的逻辑漏洞
• 密钥固定为 256 位（32 字节），导入时需显式声明 length: 256
• IV 每次生成必须随机，且严格为 12 字节（GCM 推荐长度），绝不能复用或写死
• 调用前务必检查环境：if (window.crypto && crypto.subtle)，HTTP 页面会静默失败

密钥绝不能落地，更不能写进代码

前端没有安全的密钥存储位置。密钥本身不能出现在 localStorage、cookie、URL、源码或全局变量里。可行路径只有两条：

• 用户口令派生：用 PBKDF2 + 随机 salt + ≥100,000 次迭代生成密钥；salt 可和密文一起存，但主口令只在解密时由用户输入
• 临时会话密钥：登录后调用 crypto.subtle.generateKey() 创建一次性密钥，全程仅驻留内存，页面关闭即销毁

加密后必须结构化 + Base64 编码

Web Crypto 返回的是 ArrayBuffer，不能直接塞进 localStorage。正确做法是打包后序列化：

• 把 iv、data、salt（如有） 组成对象，再 JSON 序列化：{ iv: "base64", data: "base64", salt: "base64" }
• Base64 编码推荐用 btoa(String.fromCharCode(...))，或更安全的 base64url（替换 + 和 /，去掉填充 =）
• 解密时反向操作：JSON 解析 → Base64 解码 → 构造 Uint8Array → 传给 decrypt()

哪些数据根本就别存

加密只是补救，不是保险箱。以下数据即使加密也不该进 Web Storage：

• 原始密码、JWT token、API 密钥：应交由 HttpOnly + Secure Cookie 管理，前端不持有
• 手机号、身份证号、银行卡号：前端不该长期持有，服务端按需返回脱敏结果
• 长期有效的访问令牌：必须设短过期时间（如 ≤1 小时），配合服务端黑名单机制
• 权限标识（如 isAdmin: true）：前端可被篡改，服务端必须重新鉴权