HTML5本地存储无加密功能，数据明文保存，须由开发者手动加解密；推荐Web Crypto API（如AES-GCM），禁用MD5、SHA-1、ECB等弱算法；密钥不可信，宜用PBKDF2/Scrypt口令派生或服务端协同分发；前端加密仅防设备物理访问或XSS窃取，不替代服务端保护。
HTML5 的本地存储（localStorage、sessionStorage）本身不提供加密功能，所有数据都以明文形式保存在浏览器中，直接读取即可获取。因此，加密必须由开发者在写入前手动完成，读取时再解密。
选择合适的加密方式
前端加密需兼顾安全性与性能，推荐使用标准、成熟、浏览器原生支持的方案：
- Web Crypto API（首选）：现代浏览器内置，支持 AES-GCM（带认证加密）、RSA-OAEP 等，安全性高且无需引入第三方库；
- 避免使用过时或弱算法：如 MD5、SHA-1、ECB 模式 AES（无随机性、易被模式分析）；
- 慎用纯 JS 加密库（如 CryptoJS）：部分库实现可能存在侧信道风险，且密钥仍暴露在前端内存中，无法根除“前端密钥不可信”的本质限制。
密钥管理是关键难点
前端无法安全保存密钥——任何存在 JS 中的密钥都可能被调试器、内存扫描或恶意脚本提取。可行策略包括：
- 用户口令派生密钥（PBKDF2 或 Scrypt）：用用户输入的密码 + 随机 salt 生成加密密钥，不存储密钥本身；
- 服务端协同生成临时密钥：登录后由后端返回一次性的对称密钥（经 RSA 公钥加密），仅用于本次会话的本地数据加解密；
- 绝不硬编码密钥或存于 localStorage/sessionStorage：否则等于未加密。
完整加解密流程示例（Web Crypto + PBKDF2）
以 AES-GCM 加密一段用户偏好设置为例：
立即学习“前端免费学习笔记（深入）”；
- 用户输入密码，前端生成随机 salt（如 16 字节）；
- 调用
crypto.subtle.importKey将口令和 salt 通过 PBKDF2 衍生出 256 位密钥； - 生成随机 IV（12 字节），用该密钥和 IV 对数据执行 AES-GCM 加密；
- 将 salt、IV、密文、认证标签（tag）拼接或封装为 JSON 存入 localStorage；
- 读取时解析各字段，用相同口令 + salt 重衍生密钥，验证 tag 并解密还原原始数据。
明确安全边界与替代建议
需清醒认识：前端加密无法防止用户自己解密，也不能替代服务端保护。它主要防范的是：
- 他人物理访问设备后直接读取浏览器存储文件；
- 扩展程序或 XSS 脚本批量窃取明文敏感信息（若配合 CSP 和严格 XSS 防护）。
真正敏感的数据（如令牌、密码、支付信息）应始终由后端管理，前端仅持短期、受限的访问凭证，并启用 HttpOnly Cookie、短时效 Token、定期刷新等机制。
