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）：前端可被篡改，服务端必须重新鉴权
