17370845950

JavaScript无原生AES API，前端加密不安全；真需加密应使用Web Crypto API的SubtleCrypto.encrypt()，配合AES-GCM、随机IV、非导出密钥及HTTPS环境。

JavaScript 里没有原生 AES 加密 API，别直接用 CryptoJS 或 forge 做生产环境加密

浏览器端 JavaScript 无法安全保管密钥，任何前端加密都只是“防君子不防小人”。CryptoJS 等库容易让人误以为“用了 AES 就安全了”，但密钥硬编码在 JS 文件里、或从服务端明文获取，攻击者打开 DevTools 就能照抄解密逻辑。真正需要保密的数据（如用户密码、token、敏感字段）必须交由后端处理。

真要前端加密，优先用 Web Crypto API 的 SubtleCrypto.encrypt()

这是目前唯一被现代浏览器原生支持、且密钥可隔离的方案。它要求密钥通过 importKey() 导入，且不能被 JS 直接读取（key.extractable === false）。注意以下实操要点：

• 只能在 https 或 localhost 下运行，http 页面会抛出 SecurityError
• 推荐使用 "AES-GCM" 模式（带认证），不要用已淘汰的 "AES-CBC"
• IV（初始化向量）必须每次随机生成，且需和密文一起传给后端，不能复用
• 密钥不能是字符串口令，必须用 deriveKey() 从口令 + salt 派生，或由后端下发加密后的密钥

const encoder = new TextEncoder();
const data = encoder.encode("hello world");

// 生成随机 IV
const iv = crypto.getRandomValues(new Uint8Array(12));

// 假设已有密钥 key（类型为 CryptoKey，由 importKey 得到）
const encrypted = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv },
  key,
  data
);

// encrypted 是 ArrayBuffer，需转成 base64 或 Uint8Array 传输

常见错误：把 Base64 当加密，或用 btoa()/atob() “假装加密”

btoa() 只是编码，不是加密。它等价于 Base64 编码，无密钥、无混淆、无安全性可言。开发者常把它和加密混用，结果日志里全是明文变体，Burp Suite 一抓就 decode 出来。

• btoa("admin:123") → "YWRtaW46MTIz"，毫无防护作用
• 所有前端“加密”逻辑若没密钥参与、没调用 subtleCrypto，基本等于裸奔
• JWT 的 payload 默认也是 Base64Url 编码，不是加密——别误以为加了点号就是安全的

真正该做的：前端只做最小必要加密，其余全交给 HTTPS + 后端

绝大多数场景下，你不需要在前端加密数据。正确做法是：

• 用 HTTPS 保证传输过程机密性（TLS 已解决链路加密）
• 敏感操作（如支付、改密）强制二次验证，而不是靠前端加一层“障眼法”
• 前端仅对非关键数据做轻量混淆（如埋点 ID 换 Base32，不涉及密钥）
• 密钥管理统一由后端 KMS（如 HashiCorp Vault、AWS KMS）托管，前端只申请临时加密 Token

Web Crypto 虽可用，但密钥生命周期、错误处理、降级兼容（比如 Safari 对某些 GCM 参数校验更严）都容易出错。一旦选了这条路，就得为每个浏览器版本写适配逻辑，而不是写一次就完事。