前端使用 Web Crypto API 有哪些常见误区？
简化版
Web Crypto API 提供浏览器原生加密能力，但前端使用加密很容易误解边界。常见误区包括：把密钥放前端当保密、自己设计加密算法、用普通随机数生成密钥、只加密不认证、把哈希当加密、在 XSS 存在时指望前端加密保护数据。正确做法是使用成熟协议和服务端密钥管理，前端只做必要的公钥加密、摘要校验或本地派生，并使用 crypto.getRandomValues 和 subtle API。
详细版
前端加密能保护部分传输或本地数据场景，但不能让浏览器端的秘密真正保密。
| 误区 | 问题 |
|---|---|
| 密钥写在 JS | 用户可查看和提取 |
| Math.random 生成密钥 | 随机性不够 |
| 自创算法 | 容易出错 |
| 只加密不认证 | 可能被篡改 |
| 有 XSS 还信前端加密 | 攻击者可直接调用加密逻辑 |
const bytes = crypto.getRandomValues(new Uint8Array(16))密码学里“能跑”和“安全”差得很远，前端尤其不能自造协议。
完整版教学
一、Web Crypto API 的定位
Web Crypto API 是浏览器提供的底层密码学能力，包括随机数、摘要、签名、加密、密钥导入导出等。
它比纯 JS 加密库更可靠，也更可能使用系统级实现。但 API 正确不代表使用方式一定安全。
二、前端没有保密密钥能力
浏览器端代码运行在用户设备上，用户可以打开 DevTools、抓包、断点、查看内存和源码。
所以不能把服务端密钥、私有 API key、加密主密钥写进前端。攻击者最终能拿到。
三、随机数必须用安全 API
安全随机数要用：
const iv = crypto.getRandomValues(new Uint8Array(12))不能用 Math.random() 生成 token、nonce、密钥或 IV。它不是密码学安全随机数。
四、加密要考虑认证
只加密不认证，攻击者可能篡改密文，造成解密后数据被操纵。现代对称加密常用 AEAD 模式，例如 AES-GCM，它同时提供机密性和完整性。
| 需求 | 常见选择 |
|---|---|
| 摘要 | SHA-256 |
| 密码派生 | PBKDF2、Argon2 |
| 对称加密 | AES-GCM |
| 签名 | ECDSA、RSA-PSS |
具体算法选择要跟安全团队和后端协议一致。
五、哈希不是加密
哈希是单向摘要，不能解密。它适合完整性校验、摘要比较等场景，不适合“加密保存后再还原”。
密码存储也不是简单 SHA-256，而是服务端使用带盐、慢哈希或专用密码哈希算法。
六、XSS 会破坏前端加密假设
如果页面有 XSS，攻击者脚本和你的代码运行在同一上下文里。它可以读取明文输入、调用加密函数、劫持结果或改写 UI。
因此前端加密不能替代 XSS 防护、CSP、输出转义和依赖安全。
七、常见误区与追问
- 误区：前端加密后数据就安全了。 如果密钥也在前端，攻击者可以同时拿到密钥和算法。
- 误区：Base64 是加密。 Base64 只是编码，任何人都能解码。
- 误区：Math.random 可以生成 token。 它不是密码学安全随机数，应用
crypto.getRandomValues。 - 追问：Web Crypto 适合什么场景？ 公钥加密、签名验证、摘要、本地派生、端到端加密的一部分。
- 追问：为什么推荐 AES-GCM？ 它提供认证加密，能同时防窃听和篡改。
- 追问：前端能做端到端加密吗？ 可以参与，但需要完整密钥管理、身份验证和防 XSS 方案。
八、加强记忆
Web Crypto 记成“浏览器给你的专业工具箱”，不是“把密钥藏进 JS 的魔法盒”。安全随机数、成熟算法、服务端密钥管理和 XSS 防护缺一不可。