localstorage 不应存储敏感信息,加密无法根本防范 xss 攻击;推荐用 httponly cookie 存登录态、降数据粒度、控生命周期,并上线前自查明文数据与第三方 sdk 行为。

LocalStorage 本身不提供加密能力,所有数据以明文形式存在浏览器中,直接写入敏感信息(如 token、手机号、登录态)极易被 XSS 攻击或恶意扩展窃取。加密只是“增加一层障碍”,不能替代安全设计,但配合合理策略仍可提升前端数据防护水位。
为什么加密不能解决根本问题
前端加密密钥必然暴露在 JS 代码里(硬编码、环境变量、或从服务端动态获取),攻击者只要能执行脚本,就能拿到密钥和加密逻辑,进而解密数据。XSS 一旦发生,加密形同虚设。真正敏感字段(如 access_token、身份证号、支付信息)不应出现在 localStorage 中——这是原则性底线。
若确需加密存储,推荐轻量级 AES 对称加密
不依赖外部库也可实现简易混淆(如异或+时间戳偏移),但生产环境建议使用成熟、标准化的 AES 实现。CryptoJS 是最常用选择,体积小、API 简洁、兼容 Vue/React/Uniapp:
Java JDK 25 来自 OpenJDK 官方归档,版本为 JDK 25,本条下载地址已指向官方 Windows x64 zip 安装包直链,适合调试旧项目或兼容旧版 Java 运行环境。
- 引入方式:通过 CDN 或 npm 安装
crypto-js - 密钥不要写死字符串,至少用拼接方式(如
process.env.VUE_APP_CRYPTO_KEY + 'salt_2026'),开发环境可关闭加密便于调试 - 加密前必须序列化对象(
JSON.stringify),解密后反序列化(JSON.parse),注意处理 null/undefined - 示例代码片段:
import CryptoJS from 'crypto-js'; const KEY = 'your-32-byte-aes-key-123456789012'; // 必须 32 字节(AES-256) function encrypt(str) { return CryptoJS.AES.encrypt(str, KEY).toString(); } function decrypt(encrypted) { const bytes = CryptoJS.AES.decrypt(encrypted, KEY); return bytes.toString(CryptoJS.enc.Utf8); } // 使用 localStorage.setItem('user_token', encrypt('abc123...')); const raw = decrypt(localStorage.getItem('user_token')); // → 'abc123...'
比加密更重要的三件事
单纯加密容易让人产生虚假安全感。以下措施的实际防护效果远高于前端加密:
-
换存储位置:登录态等关键凭证改用
HttpOnly + SecureCookie,JS 完全无法读取,由后端自动校验并刷新 - 降数据粒度:localStorage 只存用户 ID、昵称、主题偏好等非敏感标识;手机号、余额等每次接口按需拉取,且不在前端缓存
-
加生命周期控制:用
sessionStorage替代部分场景(关闭标签页即销毁);或自封装带过期时间的 storage(存值时附带时间戳,读取前校验是否过期)
开发阶段必须做的检查项
上线前快速自查,避免低级疏漏:
- 打开浏览器 Application → Storage → LocalStorage,确认没有明文 token、密码、完整手机号出现
- 检查所有
setItem调用点,确认敏感字段已走加密函数或已替换为后端接口调用 - 审查第三方 SDK(统计、客服、埋点),确认它们未意外读取或上报 localStorage 数据
- 在 DevTools Console 手动执行
localStorage.clear(),验证核心功能是否仍可正常登录/恢复(即不依赖本地缓存)
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










