前端AES加密这事儿我几乎每年都要在团队内部讲一轮。原因很简单只要你的系统里有登录功能就一定绕不开一个问题——用户在浏览器里输入的密码到底怎么传给后端才不那么“裸奔”。我自己早年就踩过坑当时做了一个内部管理系统登录接口直接明文传密码。安全评审的时候被人拿抓包工具演示了一遍密码在请求体里看得清清楚楚当时脸上是真的挂不住。后来老老实实补了一层AES加密再加上HTTPS才把这关过了。这篇内容我打算直接把“前端AES加密”这件事拆透重点讲清楚前端加密防的是谁、AES的核心参数怎么选、代码怎么写、以及最容易踩的坑在哪。不管你是刚接触前端的小白还是做全栈想补一下加密协作细节的开发者都能从里面找到可以直接抄作业的方案。1. 先说清楚前端做AES加密到底防什么1.1 前端加密不是用来防黑客的我见过很多刚入门的朋友对前端加密抱有一种过高的期待觉得“我把密码加密了就安全了”。这个认知需要先纠正一下。前端代码跑在浏览器里而浏览器里所有的JS代码、密钥、加密逻辑对用户来说都是可见的。任何人按下F12打开开发者工具都能看到你打包后的JS文件找到你的密钥也只是时间问题。所以从绝对安全的角度讲前端AES加密防的不是专业攻击者防的是三类“懒人”怕被人用抓包工具直接看到明文密码。浏览器开发者工具、Fiddler、Charles这类工具一抓一个准。加密之后就算请求被截获看到的也是一段密文密码不会直接暴露。怕数据库泄露之后撞库风险扩散。如果后端只存了密文就算防护不到位导致数据泄露攻击者拿到的也是密文。虽然密钥也在前端但至少提高了利用门槛。怕日志里不小心记录明文。有些网关、日志系统会把请求体打出来如果密码是明文日志就变成了泄露源。加密后日志里也是一串无意义的字符。简单来说前端AES加密解决的是“防君子不防小人”里的君子——那些无意识、顺手级别、低成本的窥探。想靠它对抗一个专职逆向工程师那不是它该干的事也不现实。1.2 前端加密在整体安全方案里的真实位置前端AES加密从来都不是安全体系的终点它只是链路里的一个环节。一条相对完整的传输安全链路应该是这样的客户端到服务器之间用HTTPS加密传输解决的是数据传输过程中被窃听的问题。前端对敏感字段做AES加密解决的是应用层日志、抓包、中间环节可见明文的问题。后端对密文做解密后再把密码做哈希存储比如加盐的bcrypt或Argon2解决的是数据库泄露后密码还原的问题。登录接口配合验证码、限流策略解决的是撞库和暴力破解的问题。这个定位很关键。你只有想清楚“前端加密补的是哪一块短板”才能正确设计安全方案而不是觉得“加了密就万事大吉”。我见过有的团队把密钥硬编码在代码里然后宣称系统“加密了很安全”这种认知比不加密码还危险因为会产生虚假的安全感。2. AES加密核心参数模式、填充、密钥和IV的选型2.1 对称加密与非对称加密怎么选AES属于对称加密加密和解密用的是同一把钥匙。与之对应的是非对称加密比如RSA、ECC加密用公钥、解密用私钥钥匙是成对出现的。很多人在设计登录加密方案时会纠结到底用AES还是RSA我的建议是大部分前端加密场景直接用AES就够原因很实在AES加解密速度快适合加密体积不大但频率高的数据比如密码、手机号、身份证号。RSA加密有长度限制通常密钥长度是1024位时最多只能加密117字节密码没问题但一段完整的用户资料就塞不下了。RSA公钥虽然可以公开但前端拿到公钥加密、后端持有私钥解密这个模型理论上比对称加密更合理。但实际中如果前端密钥管理没做好RSA的私钥也可能被拿到优势并没有想象中大。那什么时候用RSA我建议做“密钥交换”时用RSA或DH类算法做“数据加密”时直接用AES。比如一个混合方案前端随机生成一个AES会话密钥用RSA公钥加密这个AES密钥传给后端后续数据用AES加密。这样既解决了AES密钥分发问题又能享受AES加解密的高效。只是这套方案对前端的要求更高适合安全等级要求比较高的系统。2.2 AES三种常见模式与填充方式AES本身是一个分组加密算法把数据按固定长度分组处理后拼接。分组长度是128位16字节。不同模式决定了分组的处理方式我直接给你讲常见的三种模式特点适用场景注意点ECB每个分组独立加密简单快速不推荐用于业务数据相同明文分组会得到相同密文容易泄露格式信息CBC每个分组与上一个密文分组异或后再加密是最常见的模式必须依赖IVIV不能重复使用GCM带认证的加密模式密文认证标签推荐能同时保证机密性和完整性对IV随机性要求高IV通常12字节我在实际项目里最常用的是CBC和GCM。CBC在中后台项目中很常见因为大部分后端语言和加密库都原生支持互通性最好。GCM更现代自带完整性校验能够防止密文被篡改但要求前端Web Crypto API或较新的加密库支持。填充方式方面AES的固定分组长是16字节数据长度不一定是16的整数倍所以需要填充。最常见的是PKCS7同PKCS5在AES下等价OpenSSL、CryptoJS、Java默认都用它我建议你直接用默认不要自己发明填充逻辑。2.3 密钥、IV与编码格式AES-128表示密钥长度16字节AES-192是24字节AES-256是32字节。密钥越长暴力破解的成本越高但实际使用中AES-128已经足够安全AES-256因为要求更长密钥在前端硬编码时更占空间我一般默认用AES-128或AES-256看后端加密库的兼容情况。IV初始化向量是CBC/GCM模式下必需的随机参数。它的作用是让同一个明文在不同IV下产生不同密文避免相同内容加密结果一致被人看出规律。IV不需要保密但它必须随机生成、每次加密使用不同的IV并且要随密文一起传给后端。编码格式是我每次都会跟团队强调的点。AES加密结果是二进制数据但你不可能直接把二进制扔进JSON或者URL里所以需要编码。常见三种Base64最常用密文体积比原文大1/3左右适合放在JSON字段里。Hex十六进制可读性好定长无损体积比Base64更大调试时方便比对。UTF-8字符串千万别直接干这事二进制数据转成UTF-8字符串再还原时非常容易损坏。我的习惯是统一用Base64传密文和IV。3. 前端AES加密实操两种主流实现方式3.1 用CryptoJS快速落地CryptoJS是老牌的前端加密库Browser和Node环境都能用版本稳定API简单适合快速接入。先安装npm install crypto-js如果是浏览器直接用script标签引入也行它的UMD包里暴露了全局的CryptoJS对象。加密的核心代码如下import CryptoJS from crypto-js; // 约定密钥和IV16字节对应AES-128 const key CryptoJS.enc.Utf8.parse(your-secret-key); // 必须是16/24/32字节 const iv CryptoJS.enc.Utf8.parse(your-iv-value); // 必须是16字节 const secret myPassword123; // 加密 const encrypted CryptoJS.AES.encrypt(secret, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); const ciphertext encrypted.ciphertext.toString(CryptoJS.enc.Base64); const ivBase64 iv.toString(CryptoJS.enc.Base64);这里有一个容易弄混的点CryptoJS.AES.encrypt()返回的是一个CipherParams对象不是纯字符串。如果你直接调用.toString()它默认输出的是OpenSSL格式字符串包含密文和盐值但那是基于密码派生的格式后端不一定兼容。我们这里使用固定密钥IV所以应该取.ciphertext.toString(Base64)这才是纯粹的密文。对应的解密代码// 解密 const decrypted CryptoJS.AES.decrypt( { ciphertext: CryptoJS.enc.Base64.parse(ciphertext) }, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 } ); const plaintext decrypted.toString(CryptoJS.enc.Utf8);注意解密时不要再传入Base64字符串而是构造一个带ciphertext属性的对象传入。3.2 用Web Crypto API实现无依赖加密如果你不想引入任何第三方库用浏览器自带的crypto.subtle也能实现AES加密。Web Crypto API原生支持AES-CBC和AES-GCM类型安全性能也更好唯一的缺点是API偏底层写起来稍微繁琐。下面是一个AES-GCM的实现async function encryptWithGCM(plaintext) { // 1. 生成或导入密钥 const encoder new TextEncoder(); const data encoder.encode(plaintext); // 2. 生成随机IVGCM推荐12字节 const iv crypto.getRandomValues(new Uint8Array(12)); // 3. 导入密钥假设我们有一个16字节的密钥 const keyBytes encoder.encode(your-secret-key); const cryptoKey await crypto.subtle.importKey( raw, keyBytes, { name: AES-GCM }, false, [encrypt] ); // 4. 执行加密 const encrypted await crypto.subtle.encrypt( { name: AES-GCM, iv }, cryptoKey, data ); // 5. 把ArrayBuffer转成Base64方便传输 const encryptedBytes new Uint8Array(encrypted); const base64 arrayBufferToBase64(encryptedBytes); const ivBase64 arrayBufferToBase64(iv); return { base64, ivBase64 }; } function arrayBufferToBase64(buffer) { let binary ; const bytes new Uint8Array(buffer); for (let i 0; i bytes.byteLength; i) { binary String.fromCharCode(bytes[i]); } return btoa(binary); }Web Crypto API有一个重要的使用前提它必须在安全上下文中运行HTTPS或localhost。如果你用HTTP访问页面crypto.subtle是未定义的。这一点在本地联调时不明显部署到服务器上就需要注意。另外Web Crypto API中的importKey第二个参数是BufferSource如果你把密钥直接写成encoder.encode(your-secret-key)要确认编码后的字节数恰好是16/24/32。一个16个英文字母的字符串就是16字节但中文字符一个就是3字节很容易错误地超过密钥长度限制。3.3 密钥与IV的正确管理方式密钥管理是前端加密最大的难点。密钥放在前端JS代码里本质上只是混淆不是保密。但好的做法能极大提高攻击者的逆向成本。我建议按以下优先级管理密钥最基础把密钥写在独立的配置文件里不混在业务代码中至少不要满屏都是密钥字面量。进阶通过构建工具注入环境变量前端代码里引用process.env.VUE_APP_SECRET_KEY或import.meta.env.VITE_SECRET_KEY这样的变量打包后密钥进入bundle。再进阶由后端下发密钥或密钥片段。用户登录前先请求一个临时密钥前端用临时密钥加密密码。密钥每次不同历史密文作废有效防止重放攻击。高阶结合非对称做会话密钥交换。但这套方案复杂度高一般登录场景用不到。IV的管理相对简单前端每次加密时随机生成然后拼在密文后面传给后端。不要用固定IV否则同一个密码每次加密结果都一样等于告诉别人“这是同一份密码”。4. 完整项目案例登录接口密码加密落地4.1 需求拆解与协议设计假设我们有一个常规的登录接口后端是Java/Node.js前端是Vue或React。改造目标把前端提交的密码从明文变成AES-CBC密文。接口协议我通常这样设计{ username: zhangsan, password: 6fTtVq9yZx..., iv: a1b2c3d4e5f6g7h8 }每次登录请求中的iv都是随机的password是基于该IV加密后的密文后端用同一个AES密钥和IV解密得到明文密码。密钥约定前后端各保存一份16字节密钥比如约定为abc123def456ghi7示例实际应使用更复杂的随机串。这个密钥就可以认为是“共享密钥”不在网络中传输。为什么IV要作为参数传因为后端解密必须用同一个IV。前端每次随机生成一个新IV所以必须把IV带给后端。IV本身无需保密明文传输没问题。4.2 前端代码实现登录页里的核心逻辑我用一个工具类封装好方便全项目复用import CryptoJS from crypto-js; const SECRET_KEY CryptoJS.enc.Utf8.parse(abc123def456ghi7); const IV_LENGTH 16; export function encryptPassword(plainPassword) { const iv CryptoJS.lib.WordArray.random(IV_LENGTH); const encrypted CryptoJS.AES.encrypt(plainPassword, SECRET_KEY, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); return { password: encrypted.ciphertext.toString(CryptoJS.enc.Base64), iv: iv.toString(CryptoJS.enc.Base64) }; }登录请求时直接调用import { encryptPassword } from /utils/crypto; function handleLogin(username, plainPassword) { const { password, iv } encryptPassword(plainPassword); return request.post(/api/login, { username, password, iv }); }这里有个小细节CryptoJS.lib.WordArray.random(16)生成的是随机的16字节WordArray长度正好是16字节符合AES-CBC对IV的要求。不要自己用Math.random()拼字符串伪随机数有可预测性密钥IV类的东西必须用密码学安全的随机源。4.3 后端解密验证细节后端如果是Node.js用内置的crypto模块就能解const crypto require(crypto); function decryptPassword(passwordBase64, ivBase64) { const key Buffer.from(abc123def456ghi7, utf8); const iv Buffer.from(ivBase64, base64); const encrypted Buffer.from(passwordBase64, base64); const decipher crypto.createDecipheriv(aes-128-cbc, key, iv); decipher.setAutoPadding(true); let decrypted decipher.update(encrypted, base64, utf8); decrypted decipher.final(utf8); return decrypted; }后端如果是Java对应的解密核心代码大致是String key abc123def456ghi7; String iv a1b2c3d4e5f6g7h8; byte[] keyBytes key.getBytes(StandardCharsets.UTF_8); byte[] ivBytes Base64.getDecoder().decode(iv); byte[] encryptedBytes Base64.getDecoder().decode(password); Cipher cipher Cipher.getInstance(AES/CBC/PKCS5Padding); SecretKeySpec keySpec new SecretKeySpec(keyBytes, AES); IvParameterSpec ivSpec new IvParameterSpec(ivBytes); cipher.init(Cipher.DECRYPT_MODE, keySpec, ivSpec); byte[] plainBytes cipher.doFinal(encryptedBytes); String plainPassword new String(plainBytes, StandardCharsets.UTF_8);这里提醒一点Java里声明的AES/CBC/PKCS5Padding和Node.js里的aes-128-cbc默认填充是等价的PKCS5在AES场景下就是PKCS7不用担心跨语言不兼容。真正容易出问题的是密钥字节数Java里getBytes()默认平台编码如果你在中文Windows环境下不指定UTF-8密钥可能变成别的字节序列导致加解密两边结果对不上。务必显式指定字符集。整个流程跑通之后抓包工具里看到的password就是一串Base64密文每个请求的iv都不一样同一个账号密码在两次登录请求里密文完全不同。这已经达到上线标准了。5. 常见问题与排查技巧实录5.1 解密出来是乱码或者空值这是我遇到过最多的问题。排查思路固定三步先确认密钥和IV的字节长度。AES-128要求密钥16字节、IV16字节。CryptoJS.enc.Utf8.parse(abc)如果密钥是不足16字节的字符串会直接报错或者解密出空值。你可以打印.sigBytes或者toString()看一下内容长度。确认编码格式统一。前端密文转成了Base64后端也必须按Base64解码。有的后端人员习惯先new String(Base64.getDecoder().decode(...))转成String再去解密这一转就把二进制搞坏了。确认解密时没有被工具自动处理。比如有的Java同事用Cipher.getInstance(AES)不指定模式和填充默认是ECB模式和前端CBC对不上最后解密出来就是乱码。我自己总结了一个口诀密钥比对齐、模式比一致、编码比统一、IV比相同。这四个维度都排查完99%的加解密互通问题都能解决。5.2 密钥长度和模式选择导致的报错有的前端库在密钥长度不匹配时不会给一个友好的报错而是直接抛出类似“Malformed UTF-8 data”的异常。这时候不要慌先量一下密钥字节数。我有一个习惯在加密工具类里加一个初始化时的断言提前发现这种低级错误if (SECRET_KEY.sigBytes ! 16 SECRET_KEY.sigBytes ! 24 SECRET_KEY.sigBytes ! 32) { throw new Error(Invalid AES key length: must be 16, 24 or 32 bytes); }另外提醒CryptoJS.enc.Utf8.parse(abc123def456ghi7)解析出来是16字节没问题。但如果是CryptoJS.enc.Utf8.parse(abcdef)这种正好12字节的字符串AES不支持立即就会报错。很多初学者会误以为“密钥随便写”实际上密钥长度是硬性规定。5.3 跨语言互通踩过的坑前端用CryptoJS后端用Java或者前端Web Crypto API、后端用Go语言不同但AES算法本身是标准化的。只要四个参数一致结果必然互通。我整理了一张对照表方便你和后端同事对齐参数CryptoJSJavaNode.js cryptoGolang密钥长度16/24/32字节同左同左同左模式CBCCBCaes-128-cbccipher.NewCBCEncrypter填充Pkcs7PKCS5Padding默认(自动填充)cipher.BlockSizeIV16字节16字节16字节16字节最常见的坑是Java后端用了AES/CBC/NoPadding要求明文必须是16字节的整数倍密码长度11个字节时直接抛异常或者Golang后端只处理了加密没处理填充两边怎么都对不上。解决方法很简单统一用PKCS7/PKCS5填充明文任意长度都能处理。5.4 隐私保护和内容安全注意事项在落地这套方案的时候有一些边界问题也需要处理好前端加密只应该覆盖真正敏感的字段比如密码、身份证号、手机号。不要把整个请求体都加密否则网关、日志系统、排障工具全都看不到内容出问题时定位会非常痛苦。密钥不要写死在Git仓库里被多少人围观。可以用构建时的环境变量注入并且在密钥泄露后能快速轮换。轮换方式可以是前端配置里加一个密钥版本字段后端按版本选择解密密钥。明文密码在前端加密前不要顺手放在console.log里打印出来。别觉得“反正加密了”一旦浏览器日志被人看到明文密码就泄露了。不要在URL query参数里传递密文。URL会被浏览器历史、代理服务器等记录密文虽然看不出明文但有被重放的风险。在实际项目中我还建议给登录接口加一个简单的限流比如同一IP一分钟内最多登录10次。因为就算有AES加密攻击者也仍然可以把捕获的密文直接重放给服务端限流可以降低这种风险。另一点是登录成功后前端要清理敏感变量不要长时间把密钥、IV、明文密码挂在全局作用域里。按我这些年做前端安全改造的经验AES加密这件事本身不复杂真正费时间的是前后端对齐、踩坑排查和安全边界的意识。把这个基本功打牢后续再做更深入的加签、会话管理都会顺手很多。最后提醒一句前端加密是手段不是目的永远要往后端存储、传输链路、运维规范这几个方向多想一层。