17370845950

前端JavaScript加密不等于安全加密，因代码、密钥、逻辑完全暴露，仅能防低门槛窃取；Web Crypto API是唯一可信原生方案，但密钥须后端分发或PBKDF2派生，AES-GCM推荐用于对称加密，Base64等仅为编码非加密，敏感操作应移至后端。

前端 JavaScript 加密 ≠ 安全加密

JavaScript 在浏览器中运行，所有代码、密钥、逻辑都对用户完全可见。这意味着 localStorage 里存的密钥、crypto.subtle 里用的 importKey、甚至混淆过的 AES 函数，只要在客户端执行，就无法防止被逆向或绕过。所谓“前端加密”，实际只能做到「防低门槛窃取」或「满足协议格式要求」（比如把密码转成 base64 传给后端），而不是真正保护敏感数据。

Web Crypto API 是唯一可信赖的原生加密能力

现代浏览器（Chrome 68+、Firefox 60+、Safari 16.4+）支持 window.crypto.subtle，它提供符合标准的 AES-GCM、RSA-OAEP、HMAC、SHA-256 等算法，且密钥可标记为 extractable: false，防止被导出。但注意：密钥仍需由后端安全分发或通过密码派生（如 PBKDF2），不能硬编码在 JS 里。

• 对称加密推荐用 AES-GCM：支持加密 + 认证，避免手动拼接 IV 和 MAC
• 非对称加密只用于密钥交换或签名，不要用它直接加密大量数据（性能差、有长度限制）
• SubtleCrypto.generateKey() 创建的密钥必须用 exportKey() 显式导出才能序列化，否则无法跨页面/会话使用

const encoder = new TextEncoder();
const data = encoder.encode("hello");
const key = await crypto.subtle.generateKey({ name: "AES-GCM" }, true, ["encrypt", "decrypt"]);
const iv = crypto.getRandomValues(new Uint8Array(12));
const encrypted = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv },
  key.key,
  data
);

Base64、Hex、URL 编码不是加密，只是编码

很多项目误把 btoa()、Buffer.toString('hex')（Node.js）、encodeURIComponent() 当作“加密”。它们无密钥、无混淆、可逆性极强，仅用于数据格式适配（比如让二进制塞进 JSON 字段或 URL 参数），不提供任何安全性。

• btoa("admin:123") → "YWRtaW46MTIz"，用任意在线工具秒解
• 前端用 sha256 对密码哈希再提交？除非配合服务端 salt + 多轮迭代（如 PBKDF2），否则彩虹表可直接破解常见密码
• 第三方库如 crypto-js 默认使用弱 IV（全零）和 ECB 模式（已弃用），不配置 mode 和 padding 就用，等于没加锁

真正该做的：把加密逻辑移出前端

敏感操作——比如支付签名、文档加解密、用户私钥管理——应由后端完成。前端只负责收集输入、调用 HTTPS 接口、展示结果。若必须前端参与（如端到端加密聊天），则：

• 密钥永不落地：用 crypto.subtle.generateKey() 创建，extractable: false，内存中使用完即丢
• 密码派生必须用 PBKDF2 或 scrypt（Web Crypto 支持前者），迭代次数 ≥ 100,000
• 避免在 console.log()、localStorage、URL query 中暴露密文、IV、salt

最常被忽略的一点：即使用了 AES-GCM，如果 IV 重复使用，攻击者就能恢复明文——而前端用 Math.random() 生成 IV 是灾难性的。务必用 crypto.getRandomValues()。