一提到数据加密，不少人第一反应是“有HTTPS不就行了”。确实，HTTPS是传输安全的基石，但它并不能覆盖所有风险：浏览器插件可能嗅探表单、某些企业内网会做HTTPS解密审计、密码管理器或埋点脚本也可能在数据发出前读到明文。客户端加密的意义在于，让敏感数据在离开业务代码的那一刻就已经是密文，即使中间环节被窥探，拿到的也只是一串无法解读的字节。这篇文章就用JavaScript实际操作一遍客户端加密的核心流程，并谈谈如何把加密做对、做稳。
先想清楚：什么情况下需要客户端加密
客户端加密不是万能药，用错了反而会给人虚假的安全感。最常见的合理场景是登录密码的处理：即使服务器已经用了bcrypt等慢哈希，前端先做一层加密（或哈希加盐）可以避免原始密码以明文形式经过任何网络中间层，也能防止开发者工具的网络面板里直接躺着用户的密码。
第二个场景是端到端加密的即时通讯、私密笔记类应用。这类需求下服务器只做密文中转，解密只发生在通信双方的浏览器里，服务端本身都看不到明文。第三个场景是金融、医疗等合规要求严格的业务，某些行业标准明确要求敏感字段在客户端完成加密后才能提交。
反过来说，如果你的数据只是展示给用户看的公开内容，或者系统内部的状态字段，强行加一层前端加密只会增加调试成本，得不偿失。另外要明确一个原则：客户端加密是HTTPS的补充，不是替代。先上HTTPS，再考虑客户端加密，顺序不能颠倒。
用Web Crypto API实现AES-GCM加密
现代浏览器都内置了crypto.subtle对象，也就是Web Crypto API。它由浏览器原生实现，经过了大量安全审计，比引入第三方加密库更值得信任。对称加密推荐使用AES-GCM模式，它同时提供机密性和完整性校验，一旦密文被篡改，解密时会直接抛错，不需要你额外写校验逻辑。
下面是一段完整的可运行代码，涵盖密钥生成、加密和解密三个步骤：
// 将字符串编码为字节数组
function str2buf(str) {
return new TextEncoder().encode(str);
}
// 生成256位AES-GCM密钥
async function genKey() {
return crypto.subtle.generateKey(
{ name: 'AES-GCM', length: 256 },
true, // 密钥可导出，便于存储或传输
['encrypt', 'decrypt']
);
}
// 加密：每次生成随机12字节IV
async function encryptData(key, plaintext) {
const iv = crypto.getRandomValues(new Uint8Array(12));
const cipher = await crypto.subtle.encrypt(
{ name: 'AES-GCM', iv: iv },
key,
str2buf(plaintext)
);
return { iv, cipher: new Uint8Array(cipher) };
}
// 解密
async function decryptData(key, iv, cipher) {
const plain = await crypto.subtle.decrypt(
{ name: 'AES-GCM', iv: iv },
key,
cipher
);
return new TextDecoder().decode(plain);
}
// 使用示例
(async () => {
const key = await genKey();
const { iv, cipher } = await encryptData(key, '用户的敏感信息');
console.log('密文长度:', cipher.length);
const text = await decryptData(key, iv, cipher);
console.log('解密结果:', text);
})();这段代码里有几个细节值得展开。第一，IV（初始化向量）必须是随机且不可重复的，GCM模式下同一密钥重复使用相同IV是灾难性的安全问题，所以每次加密都调用crypto.getRandomValues生成新的12字节IV。第二，IV本身不是秘密，可以和密文一起明文传输，服务端拿到IV后配合密钥即可解密。第三，密文需要转成Base64或Hex才能放进JSON提交，可以用btoa(String.fromCharCode(...cipher))配合处理。
混合加密：解决密钥分发难题
对称加密速度快，但有个绕不开的问题：浏览器里生成的密钥怎么安全地告诉服务器？如果直接把密钥随请求发出去，那加密就形同虚设。业界标准做法是混合加密：用非对称算法（RSA或ECDH）协商出会话密钥，再用这个会话密钥做AES对称加密。
以RSA方案为例，流程是这样的：服务器生成RSA密钥对，把公钥下发给前端；前端每次生成一个随机的AES密钥，用RSA公钥加密这个AES密钥，再用AES密钥加密真正的业务数据；服务端用私钥解出AES密钥，再解密业务数据。代码大致如下：
// 导入服务端下发的RSA公钥（PEM格式）
async function importRsaPublicKey(pem) {
const pemBody = pem
.replace(/-----BEGIN PUBLIC KEY-----/, '')
.replace(/-----END PUBLIC KEY-----/, '')
.trim();
const binary = Uint8Array.from(atob(pemBody), c => c.charCodeAt(0));
return crypto.subtle.importKey(
'spki',
binary,
{ name: 'RSA-OAEP', hash: 'SHA-256' },
false,
['encrypt']
);
}
// 混合加密：RSA加密AES密钥，AES加密数据
async function hybridEncrypt(rsaPubKey, plaintext) {
const aesKey = await genKey(); // 复用上文的AES密钥生成
const { iv, cipher } = await encryptData(aesKey, plaintext);
// 导出AES密钥并用RSA公钥加密
const rawAesKey = await crypto.subtle.exportKey('raw', aesKey);
const encryptedKey = await crypto.subtle.encrypt(
{ name: 'RSA-OAEP' },
rsaPubKey,
rawAesKey
);
return { encryptedKey, iv, cipher };
}更现代的选择是ECDH密钥交换，浏览器生成临时椭圆曲线密钥对，与服务端公钥做Diffie-Hellman协商，双方各自推导出相同的共享密钥，全程没有任何密钥本身在网络上传输。ECDH的密钥更短、运算更快，而且配合deriveKey方法可以直接推导出AES密钥，实现前向 secrecy——即使服务端长期私钥将来泄露，历史会话也无法被解密。对于新项目，建议优先考虑ECDH方案。
防重放与防篡改：加密之外的完整性保障
只做加密还不够。攻击者虽然读不懂密文，但可以把截获的密文原样重发给服务器，这就是重放攻击。比如登录请求被重放，可能在用户已退出后再次触发操作。标准对策是请求体里加入时间戳和随机数（nonce），服务端校验时间戳偏差（一般允许5分钟以内），并记录已使用的nonce拒绝重复提交。
防篡改则依靠签名。用HMAC对“时间戳 + nonce + 密文”整体计算摘要，服务端用同样的密钥重新计算并比对，任何一个字段被改动都会导致签名不匹配。HMAC在Web Crypto里也有原生支持：
// 用HMAC-SHA256对请求数据签名
async function signPayload(hmacKey, message) {
const sig = await crypto.subtle.sign(
'HMAC',
hmacKey,
str2buf(message)
);
return new Uint8Array(sig);
}
// 组装完整的加密请求体
async function buildSecureRequest(data) {
const timestamp = Date.now().toString();
const nonce = crypto.getRandomValues(new Uint8Array(8))
.reduce((s, b) => s + b.toString(16).padStart(2, '0'), '');
const payload = JSON.stringify(data);
const { encryptedKey, iv, cipher } = await hybridEncrypt(pubKey, payload);
const signTarget = timestamp + nonce + b64(cipher);
const signature = await signPayload(hmacKey, signTarget);
return {
timestamp, nonce,
encryptedKey: b64(encryptedKey),
iv: b64(iv),
data: b64(cipher),
signature: b64(signature)
};
}这样一来，一个请求同时具备机密性（AES-GCM加密）、完整性（GCM认证标签加HMAC签名）和唯一性（nonce加时间戳），攻破的难度会大幅上升。服务端实现对应的校验逻辑后，这套方案就形成了闭环。
几个必须避开的坑
第一个坑是自己发明加密算法或拼接加密方案。加密是极其精密的领域，IV错一个字节、填充方式选错、密钥派生缺少盐值，都会让整套防护形同虚设。永远使用标准库和标准算法组合，除非你有一个密码学专家团队做审查。
第二个坑是把密钥硬编码在前端代码里，比如写死一个AES密钥字符串打包进JS文件。前端代码对所有人可见，等于把家门钥匙挂在门把手上。正确的做法是密钥每次会话动态生成，通过混合加密或密钥交换获得。第三个坑是用Math.random生成IV或密钥，它不是密码学安全的随机源，必须用crypto.getRandomValues。第四个坑是加密后忽略错误处理——GCM解密失败会抛异常，务必用try...catch捕获并按安全事件处理，而不是让异常裸奔到控制台。
最后再强调一次优先级：HTTPS是地基，客户端加密是加固层，服务端校验是最后防线。三层各司其职，任何一层都不能因为有了其他层就偷工减料。把Web Crypto API的标准用法、混合加密的密钥分发、时间戳加签名的请求防护这三件事做扎实，你的前端数据安全水平就已经超过大多数应用了。
JavaScript加密Web Crypto API数据安全传输修改时间：2026-09-12 12:08:47