1. 为什么JavaScript需要加解密先理清概念和应用场景搞前端开发这些年经常有同事拿着一个需求过来问我帮我在前端把这个密码加密一下呗。每次遇到这种诉求我都得先拉把椅子坐下问清楚他到底想防谁、防什么、从哪里防到哪。因为JavaScript加解密这件事最大的尴尬在于你有多少代码逻辑用户就能看到多少代码逻辑。你要是以为把加密逻辑写在前端就等于上了保险那企业级的安全实践也就无从谈起了。那JavaScript加解密到底解决什么问题我用一句人话概括它解决的是数据在传输过程中被窃听、被篡改、被伪造的风险而不是数据在用户手里被破解的风险。换句话说前端加解密真正的用武之地是保护客户端和服务端之间的链路安全、校验数据完整性、防止参数被恶意篡改以及在某些特定场景下保护数据库侧的静态数据——而不是让前端藏着掖着一个天知地知你知我知的密钥。这篇文章的受众我定位为两类人一类是刚接触加解密概念的初中级前端想搞清楚AES、RSA、SHA、HMAC这些词到底怎么回事另一类是已经在项目里踩过加解密坑、想系统梳理企业级方案的工程师。我不会绕弯子会从头到尾讲清楚原理、选型、代码实现和真实项目里踩过的坑顺便把我自己调试过的加密方案和失败教训一并交代出来。这里说一句更重要的话JavaScript加解密并不比后端加解密低级只是它的防御边界不同。理解了这个边界你才能真正设计出一套合适的方案而不是照抄一段网上捞到的AES加密代码就往生产环境里塞。我下面讲的每一个技术点都是围绕边界这两个字展开的。2. 理论基础加密、哈希、签名到底分别承担什么任务2.1 加密、哈希与签名三兄弟功能完全不同很多初学者容易把MD5、AES、SHA、RSA、HMAC混为一谈以为它们都是把数据弄乱让人看不懂。这种理解在入门阶段可以原谅但一旦涉及真实业务设计就必须分清楚它们是三个层面的东西。加密Encryption可逆操作。用密钥把明文变成密文目的是保密不让无关人员读懂内容。代表算法有AES对称、RSA非对称。哈希Hash不可逆操作。把任意长度的数据映射成固定长度的摘要目的是校验完整性不能还原原文。代表算法有SHA-256、MD5。签名/消息认证码Signature/HMAC在一个数据上附加一段证明让接收方确认数据确实来自声称的发送方、且中途没有被篡改。代表算法有RSA签名、HMAC-SHA256。用生活类比来理解加密相当于把一个日记本锁进保险箱有钥匙的人才能打开读内容哈希相当于给一篇文章算出一个指纹文章被改一个字指纹就变了但你没法从指纹反推出文章内容签名相当于在信封上盖一个官方印章收信人一看印章就知道寄件人是谁印章或信件任何一处被动过收信人都能发现。这三者之间并非互斥实际方案中经常一起上。比如用AES加密业务数据保证机密性用SHA-256算摘要校验完整性再用HMAC或RSA签名确认来源可信。在企业级接口设计中你会经常看到加密签名的组合目的就是同时解决保密、完整和不可否认这三个安全要素。2.2 对称加密与非对称加密各自的优势和在场时机对称加密就是加密和解密用同一把密钥。它的优点是速度快、对长数据友好缺点是密钥怎么安全地交给对方是个麻烦问题。项目里最常见的对称算法是AES密钥长度128位、192位、256位我的建议是业务场景直接用AES-256-GCM原因后面会细讲。非对称加密使用一对密钥公钥负责加密私钥负责解密或反过来私钥签名、公钥验签。典型的算法是RSA和ECC。它的优点是密钥分发方便——公钥随便给人私钥自己留着缺点是性能差加密长度受限。RSA-2048加密一小段数据比如AES密钥没问题但要用它加密整个文件或大JSON那性能会让人崩溃。于是工程上就有了一个非常经典的组合方案混合加密。用RSA加密AES的对称密钥再用AES加密真正的业务数据。RSA负责解决密钥怎么安全传给对方AES负责解决大量数据快速加解密。这在HTTPS的TLS握手过程中就是标准做法我们自己在业务层做加解密时也完全可以参考这个思路。2.3 哈希算法的选择MD5与SHA家族的正确认知MD5现在已经不适合用于安全敏感场景了它被碰撞攻击打得毫无还手之力——你可以构造两个内容不同但MD5值完全一样的文件。这听起来可能很抽象但在文件签名校验、软件下载校验这类场景中如果仍用MD5攻击者完全可以伪造一个恶意文件却让校验值看起来和官方一致。所以凡是涉及安全防御的地方至少用SHA-256。SHA-256在目前算力水平下还没有实用意义上的碰撞攻击企业内默认选择SHA-256不会有错要求更高时还可以考虑SHA-384或SHA-512。哈希在JavaScript里的常见用途有这么几类接口报文摘要校验、密码存储的加盐哈希、文件分片上传的完整性校验、以及配合HMAC做消息认证。我特别想强调一点存密码不要用普通哈希要用慢哈希算法比如bcrypt、scrypt或PBKDF2。普通哈希SHA-256也好MD5也罢算得太快攻击者拿字典跑起来毫不费力。慢哈希算法的核心思路就是故意让每一次计算变慢让暴力破解的成本高到承受不起。JavaScript端如果必须在浏览器里做PBKDF2派生Web Crypto API是支持PBKDF2的使用时记得选足够大的迭代次数至少数万到十万次以上具体视设备性能而定。3. 浏览器端加密技术选型Web Crypto API与第三方库之争3.1 Web Crypto API现代浏览器的原生正规军如果你还在用纯JavaScript手写加密算法或者优先考虑引入crypto-js这个库我建议你先停下来看看浏览器的原生能力。window.crypto.subtle是W3C标准定义的一套加解密接口几乎所有现代浏览器都已支持。它最大的优势有三个性能好底层用操作系统或硬件加速的加密原语、安全性高密钥可以用CryptoKey对象管理不直接暴露在JavaScript变量里、标准统一不需要额外引入第三方依赖减少供应链风险。不过Web Crypto API有一个让人挠头的门槛它的所有核心方法几乎都是异步的返回Promise而且随机数生成、密钥导入导出都有比较繁琐的格式要求。很多新手第一次用的时候连怎么把字符串转成ArrayBuffer都折腾了半天这是正常的因为它是为性能和底层安全设计的API不是为人类友好设计的API。我在后面的实操章节里会写完整的示例底部明确展示如何走完字符串到加密结果的每一步。3.2 CryptoJS这类库还有没有存在价值CryptoJS是老牌的JavaScript加密库封装了AES、DES、TripleDES、Rabbit、RC4、MD5、SHA等大量算法API友好度比Web Crypto API高出一大截。但说实话CryptoJS这些年更新频率很慢而且它内部对随机源的管理不如浏览器原生实现可靠——在浏览器环境里你最好手动传入足够随机的IV否则可能出现可预测的密钥或IV这是我不建议新项目直接依赖CryptoJS做高安全需求的原因。那CryptoJS还有没有适用场景有的。对于非浏览器环境、或者对随机性和密钥管理要求不那么极端的内部工具、原型Demo、Node.js脚本CryptoJS靠丰富的算法支持和最简单的API能大幅提高开发效率。但如果做的是面向真实用户、处理敏感数据的企业级前端我的选择是尽量用Web Crypto API把第三方依赖面压到最小。3.3 正确姿势先把环境能力摸清楚再选型在动手写代码之前我的建议是先回答这几个问题项目运行环境是什么现代浏览器、老版本浏览器还是WebView内嵌页面加密操作是服务端主导前端只负责调用接口还是需要前端独立完成对包体积、加载性能的要求是怎样的密钥来源是什么固定密钥、服务端下发的动态密钥、还是客户端本地生成这些问题直接决定了选型方向。如果你们的产品还需要兼容IE11这类老古董那Web Crypto API就别想了只能用polyfill或第三方库方案如果所处环境是较新版本的Chromium内核那Web Crypto API绝对是优先级最高的选择。我在实际项目中就吃过一次亏想当然地用了Web Crypto API的AES-GCM结果测试环境有个老平板内置浏览器不支持后来不得不降级方案——选型之前花十分钟做一个兼容性检查能省掉后面一大串麻烦。4. 企业级实战基于AES-GCM与RSA混合加密的完整设计4.1 混合加密的整体逻辑与数据流设计现在进入本文最核心的实操环节。我以一套登录接口的密码传输与用户敏感数据保护为例完整演示一套企业级混合加密方案是怎么设计、拆解和落地的。整体思路是这样的服务端生成一对RSA密钥对公钥可以在前端初始化时通过接口下发或者直接内置在前端代码里取决于业务对公钥轮换的要求前端随机生成一个AES密钥也叫会话密钥只用于本次请求或本此会话用这个AES密钥加密真实业务数据再用RSA公钥加密这个AES密钥最后把RSA加密后的AES密钥和AES加密后的业务密文一起发送给服务端。服务端拿到后先用RSA私钥解出AES密钥再用AES密钥解出业务明文。这样设计有一个很直接的好处即便攻击者能截获全部通信内容他没有RSA私钥就拿不到AES密钥数据对他来说就是一堆乱码。而AES加密大体积业务数据的速度优势完全被保留下来RSA只加密小小一段密钥性能开销可以忽略不计。这套思路其实就是TLS这样成熟协议采用的混合加密模式我们把它搬到自己业务里安全性比单纯用任何单一算法都高一个量级。4.2 密钥管理细节密钥格式、编码与轮换策略企业级方案的重点其实不在算法编码本身而在密钥管理。我见过很多项目AES密钥直接写死在前端代码里三个字母的固定IV用了一年半载这种方案别人逆向一下JS就全暴露了。密钥管理的核心原则有三条密钥不能直接硬编码在前端。前端密钥应该由服务端下发或由前端随机生成后通过非对称加密传输给服务端。每次会话使用独立密钥。周期性更换会话密钥至少要保证一次请求或一个会话一把密钥避免长期复用的风险。公钥可以公开私钥绝对保密。RSA公钥挂在公网没有任何问题但私钥一旦泄露就相当于所有通信都裸奔了所以私钥应该放在服务端受控环境权限最小化。用Web Crypto API生成RSA密钥对、导出公钥并导入的代码如下我后面会放在实操片段里。这里先说一个很重要但很容易被忽略的细节Web Crypto API导出的公钥默认是SPKI格式一般用base64编码传输私钥导出是PKCS8格式除非有特殊需求不要把私钥推到前端哪怕只是测试也不行。4.3 前端实现核心API逐行讲解下面给出一套我在项目中验证过可以直接跑通的实现。先看RSA密钥对生成和导出// 生成RSA-2048密钥对 const keyPair await crypto.subtle.generateKey( { name: RSA-OAEP, modulusLength: 2048, publicExponent: new Uint8Array([1, 0, 1]), hash: SHA-256 }, true, [encrypt, decrypt] ); // 导出公钥SPKI格式并转为base64 const spki await crypto.subtle.exportKey(spki, keyPair.publicKey); const publicKeyBase64 arrayBufferToBase64(spki); // 导出的私钥只用于测试演示生产环境绝不导出私钥到前端 const pkcs8 await crypto.subtle.exportKey(pkcs8, keyPair.privateKey);注意generateKey的第三个参数extractable设为true才能导出但在生产环境中如果你的私钥只用于服务端解密前端根本没有必要生成RSA密钥对——前端只需要拿到一个公钥即可。上面的生成示例主要供你在本地调试时模拟完整流程用。再看公钥导入与AES密钥生成// 后端下发的公钥是base64字符串先转回ArrayBuffer再导入 function base64ToArrayBuffer(base64) { const bin atob(base64); const bytes new Uint8Array(bin.length); for (let i 0; i bin.length; i) { bytes[i] bin.charCodeAt(i); } return bytes.buffer; } const publicKey await crypto.subtle.importKey( spki, base64ToArrayBuffer(publicKeyBase64), { name: RSA-OAEP, hash: SHA-256 }, false, [encrypt] ); // 生成一个128位16字节的AES-GCM密钥 const aesKey await crypto.subtle.generateKey( { name: AES-GCM, length: 128 }, true, [encrypt, decrypt] );然后是加密业务数据、加密AES密钥并组装请求包const encoder new TextEncoder(); const dataBuffer encoder.encode(JSON.stringify({ username: alice, password: xxx })); // 随机生成12字节IV const iv crypto.getRandomValues(new Uint8Array(12)); // 用AES-GCM加密业务数据 const ciphertext await crypto.subtle.encrypt( { name: AES-GCM, iv }, aesKey, dataBuffer ); // 导出AES密钥原始字节并用RSA公钥加密 const aesRaw await crypto.subtle.exportKey(raw, aesKey); const encAesKey await crypto.subtle.encrypt( { name: RSA-OAEP }, publicKey, aesRaw ); // 组装请求体 const requestBody { enc_key: arrayBufferToBase64(encAesKey), enc_data: arrayBufferToBase64(ciphertext), iv: arrayBufferToBase64(iv) }; fetch(/api/login, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify(requestBody) });这里的IV设计非常关键。AES-GCM模式要求IV不能重复使用如果同一个密钥下IV重复攻击者可以直接恢复密钥流安全性彻底崩盘。所以我每次加密都新生成一个12字节的随机IV并且把IV随密文一起传输——IV本身不需要保密它只需要唯一。这一点在官方安全文档里反复强调但实践中仍然有大量项目把IV写死这是特别危险的。arrayBufferToBase64这个辅助函数我下面给出一个可靠版本function arrayBufferToBase64(buffer) { const bytes new Uint8Array(buffer); let binary ; for (let i 0; i bytes.length; i) { binary String.fromCharCode(bytes[i]); } return btoa(binary); }整个流程的核心链路就这些。按照我过去做项目的经验把这些步骤理顺之后前端加解密部分其实并没有特别复杂的逻辑真正让人头疼的是后端如何配合、以及字符串编码各种不一致引发的偶发问题后面我会专门开一章讲。4.4 服务端配合要点与前端保持一致的算法细节前端做完了后端如果和你对齐的细节有出入那整个加密链路就白瞎了。我最怕听到的一句话就是你前端加密就行后端我随便解一下。后端必须和前端约定清清楚楚的四个细节RSA填充模式前端用RSA-OAEP后端Java里对应Cipher.getInstance(RSA/ECB/OAEPWithSHA-256AndMGF1Padding)如果用Node.js对应crypto.publicDecrypt或privateDecrypt时选RSA_PKCS1_OAEP_PADDING。AES模式与认证标签前端是AES-GCM后端对应AES/GCM/NoPadding并且注意GCM模式自带认证标签通常加密结果会附带一块额外字节解密时要做正确切分。字符编码JSON序列化统一用UTF-8。前端TextEncoder默认就是UTF-8后端不要用什么平台默认字符集显式指定UTF-8。Base64变体我用的是标准Base64不是Base64Url。如果某些网关、代理对和/字符有转义可以考虑用Base64Url并统一约定否则别混合使用。后端解密的流程就是反过来的先拿enc_key用RSA私钥解密得到AES密钥字节再用AES密钥和IV对enc_data做AES-GCM解密最后把JSON字符串反序列化。解密时一旦GCM认证失败千万不能直接忽略这说明数据被篡改过或密钥不匹配要记录安全日志并按异常处理。4.5 签名与时间戳防止重放攻击的必要屏障加密解决了机密性问题但不解决重放攻击——攻击者把截获的合法请求原封不动再发送一遍服务端无法辨别这是一个新的合法请求还是攻击者的重放。对付重放攻击常见做法是在请求体中附加时间戳和防重放随机数nonce并且服务端在短时间内记录已经处理过的nonce拒绝重复。签名在这个环节的作用是防止攻击者篡改时间戳和nonce。完整的企业级方案应该是对请求体含时间戳、nonce计算HMAC-SHA256将签名和服务端共享的签名密钥一起传输。当然如果你们走的是HTTPS并配合服务端完整的风控体系单靠加密未必需要把全部纵深都自己实现但在设计业务层安全方案时时间戳nonce签名的组合我仍然推荐这是非常成熟的防重放标准套路。用Web Crypto API计算HMAC的流程也不复杂const hmacKey await crypto.subtle.importKey( raw, encoder.encode(your-shared-signing-key), { name: HMAC, hash: SHA-256 }, false, [sign, verify] ); const signData encoder.encode(${timestamp}:${nonce}:${JSON.stringify(data)}); const signature await crypto.subtle.sign(HMAC, hmacKey, signData); // 把signature转base64后随请求发送这里的签名密钥属于服务端和前端共享的对称密钥分发方式可以复用RSA公钥加密通道也可以由服务端在会话建立阶段下发。注意签名密钥和AES加密密钥应该分开管理不要图省事用同一个密钥。5. 梳理加解密实践中的高频坑与排查方法5.1 编码问题ArrayBuffer、Uint8Array、Base64三者的混乱之源我敢说加解密项目里一半以上的诡异问题都出在编码上。前端拿到的字符串要转成ArrayBuffer才能加密加密结果是ArrayBuffer又要转回Base64才能放进JSON解密时又要Base64转回ArrayBuffer这一来一回任何一个环节的编码不对最终密文就完全解不开。这里我总结一个固定规律照着做基本不会出问题字符串转字节用TextEncoderUTF-8不要手写charCodeAt循环后者处理非ASCII字符时极容易踩坑。字节转字符串用TextDecoder同样注意UTF-8。二进制转Base64用btoa加手动遍历字节。Base64转二进制用atob加手动遍历字符。不要用String.fromCharCode直接处理多字节UTF-8字符串的加密结果必须先明确字节流是什么编码。这个坑最常见的表现就是本地加密解密调试通过一联调就挂八成就是两端编码不一致。排查思路也很简单从明文到密文两端在每一层输出都打一下base64逐层比对很快就能定位是哪一步开始不一样的。5.2 GCM模式下的IV重复与认证标签问题AES-GCM有三大经典事故现场IV重复同一个密钥下IV哪怕只重复一次攻击者就可能恢复密钥流。解决办法是随机生成且足够长12字节随机IV在加密次数较少时碰撞概率可接受但如果加密量极大或者对安全要求极致可以考虑用计数器或服务端分配的nonce。认证标签截断GCM模式的认证标签默认128位有些封装库默认截断为96位或64位。安全起见不要牺牲标签长度默认128位就好。密文和标签的拼接顺序不同库有不同的拼接习惯有的把标签放在密文尾部有的分开传输。两端必须约定一致否则解密端会把标签误认为密文的一部分导致解密后多了16字节乱码这种诡异现象。5.3 性能问题RSA加密大数据的致命隐患前面提过不建议直接用RSA加密大数据。我之前真见过一个项目后端图省事让前端用RSA公钥把整个用户资料JSON加密后POST上来结果几百字节的东西加密加了好久接口超时率飙升。后来改成混合加密方案性能回归正常。原因是RSA的加密过程涉及大整数模幂运算数据长度越长、密钥位数越大开销成倍上涨。RSA-2048加密一次大约能处理256字节左右具体取决于编码超过这个长度就得分段加密性能就更难看。所以正确的姿势永远是把RSA留给密钥交换用对称加密处理实际数据。5.4 兼容性与降级方案的取舍在引入Web Crypto API之前我习惯先写一个能力检测const isWebCryptoSupported window.crypto window.crypto.subtle;如果不支持再根据业务降级方案。可以选择引入兼容库也可以选择让服务端统一处理加解密。很重要的一点是降级方案本身也要安全。不要在降级的时候退回明文传输前端象征性混淆那等于把安全直接降为零。降级到HTTPS传输也行至少还有一层链路保护。我的建议是如果业务对安全有硬性要求老旧浏览器直接走服务端兜底逻辑而不是在前端降低安全标准。6. 从经验到建议我对JavaScript加解密的一些真心话6.1 安全是整体架构设计不是某一个算法做加解密实践这些年我最深刻的体会就是靠某一个算法拯救不了整体安全。AES-256再强如果密钥管理一塌糊涂等于给保险箱配了一把人人都有机会复制的钥匙RSA-2048再权威如果私钥放在一个权限溢出、日志乱打的环境里也形同虚设。所以企业级的安全实践一定是一个系统工程从密钥生成、密钥存储、密钥轮换、传输链路、服务端验签、风控策略、日志监控到安全响应每个环节都要有清晰的设计和兜底。前端加解密只是整体安全架构中的一环它的作用是缩小暴露面、增加攻击成本而不是成为那个唯一的安全边界。把这句话写进方案评审PPT里能够避免掉大部分前端加密后万事大吉的侥幸心态。6.2 写给自己和读者的几句实用建议按我这些年踩坑总结出来的经验几个务必牢记的要点放在这里不要自创加密算法。AES、RSA这些经过全世界密码学家验证多年的算法你不用非要自己搞一个异或加位移的私有算法那基本就是给攻击者送菜。任何自称绝对安全的私有加密方案大概率经不起专业分析。不要试图用前端加密掩盖明文漏洞。比如密码字段哪怕你用AES-GCM在前端处理了如果接口日志里还打了明文加密就白做了。排查漏洞时要查整个数据链路而不是只看传输那一层。密钥轮换和泄漏应急要提前想好。加密方案上线第一天就应该考虑好如果密钥泄漏怎么办的预案。私钥能不能在几分钟内完成替换已泄漏时间段内的数据如何处理这些问题如果等到事故发生时再想代价是灾难性的。在研发阶段把调试日志和错误提示写得足够清楚。加解密问题的一大难点就是定位慢良好的日志不记录敏感明文能省下大量联调时间。6.3 本方案还能怎么扩展如果你已经把这套混合加密方案跑通了后续还可以考虑几个方向用ECDH椭圆曲线迪菲-赫尔曼替代RSA做密钥协商获得更好的性能和更短的密文结合WebAuthn做无密码登录让私钥直接留在用户设备的安全芯片里使用crypto.randomUUID()生成请求ID和nonce做更完善的全链路日志追踪若服务端采用微服务架构还要把加解密的逻辑收敛到一个独立的加解密网关或统一SDK里避免每个服务各写一套不一致的逻辑。这些扩展方向无论是性能优化还是安全纵深都值得我们在下一阶段继续钻研。最后说一句我个人的体会JavaScript加解密的门槛并不高但把它用对地方、用成体系确实需要你对整个通信链路的极致熟悉。希望这篇实战全解能帮你在自己项目的安全设计上少走几个弯路。
