做前端时间长了你就会发现一个很现实的问题接口返回的敏感数据比如用户手机号、身份证、订单金额一旦在传输层被拦截基本就是明文裸奔。虽然业内默认 HTTPS 是标配但标配不等于万能尤其是内网系统、第三方回调、网关日志这类场景很多团队会额外约定在应用层再做一层加密。我最近在维护一个管理后台项目时就把前端接口请求和响应的加解密统一收拢到底层封装里用的就是 crypto-js 这个库做 AES 加解密整体落地效果很稳。这篇内容不是纯理论是我把 AES 加解密完整封装进前端项目后的一套实践沉淀。适合正在做前端安全加固、需要对接后端加密接口、或者面试被问到“前端怎么做加密”时不知道怎么答的朋友。看完你可以直接拿走封装代码也能搞清楚每个参数为什么这么设置后端对接时哪些细节最容易踩坑。1. 先搞清楚前端做 AES 加密到底在防什么1.1 我们防的不是“用户”而是“链路”和“日志”很多刚入行的同学一听到前端加密第一反应是“这不是脱裤子放屁吗密钥就在前端代码里用户一翻就能看到”。这个质疑有一定道理但是混淆了威胁模型。前端做 AES 加密防的不是一个拿着 DevTools 盯着你看的极客用户而是防三类很常见但不那么“高深”的问题防明文出现在网关日志和 Nginx access log 里。很多团队把请求体打到日志平台做排障一旦接口字段里有手机号、身份证这种敏感信息日志泄露等于数据泄露。加密后日志里只有一串 Base64敏感数据至少不会以明文形式落盘。防止第三方渠道抓包后直接“抄作业”。在一些 B 端系统里请求结构被爬虫抓下来之后别人不需要破解你的业务只需要照着参数格式重放一次就能薅数据。加密后重放的成本高很多。防止公共 WiFi 或者内网镜像端口下的被动嗅探。虽然 HTTPS 能解决大部分问题但总有些历史系统证书配置不规范、内网 HTTP 服务没收敛应用层加密是一道额外的保险不是替代品。理解了这三个目标你就能明白前端加密不是要做成“绝对无法破解”而是要把破解成本和数据价值拉到不成比例让攻击者觉得不划算。这个定位很重要否则你会在密钥管理上陷入无休止的内耗。1.2 为什么选 crypto-js 而不是 Web Crypto API 或自研选型的时候我对比过三条路浏览器自带的 Web Crypto API、自研加密函数、crypto-js。Web Crypto API 性能好、原生支持、没有依赖体积但它的 API 设计偏底层异步 Promise 满天飞而且不同浏览器的实现细节有差异老项目要兼容 IE 的话直接 pass。另外 Web Crypto 的 GCM 模式虽然安全但封装成本对普通业务项目来说略高。自研加密函数这个选项我直接排除了。AES 加解密涉及密钥扩展、S 盒替换、列混合这一整套分组密码学自己写既容易出致命漏洞又浪费时间。我见过有人为了“省一个依赖”自己手写了一个异或加密结果把用户手机号编码成 Base64 就当加密了这种属于自己骗自己。crypto-js 的优势很明显API 简单、同步执行、体积小压缩后大概 40KB 左右、支持多种算法而且对老浏览器兼容性好。虽然它的维护节奏不如原生 API 积极但 AES 加解密这种底层标准算法已经被验证得非常充分用起来很放心。对普通后台管理系统和业务前端来说crypto-js 是性价比最高的选择。1.3 AES 要懂的三个核心参数密钥、IV、模式AES 本身是一个分组加密算法但实际使用中你还需要组合几个参数任何一个对不上后端就解不开。这也是前端和后端联调时最容易扯皮的地方。第一个是密钥长度。AES 支持 128 位、192 位、256 位三种密钥长度对应 16 字节、24 字节、32 字节。现在主流推荐 AES-256也就是 32 字节密钥。不要为了“省事”用 8 位数字当密钥AES 的密钥必须按字节长度严格对齐。第二个是分组模式。crypto-js 里常用的是 ECB 和 CBC。ECB 模式相同明文会得到相同密文容易泄漏数据模式能不用就别用。CBC 模式引入了 IV初始化向量相同明文配合不同 IV 会得到不同密文安全性更好是默认的实践选择。如果后端要求更高级的 GCM 模式crypto-js 原生不支持需要扩展或走 Web Crypto API这个后面单独说。第三个是填充方式。AES 分组长度 16 字节明文最后一组不足 16 字节时需要填充。crypto-js 默认用 Pkcs7而 Java 的 PKCS5Padding 和 PKCS7 在 AES 场景下是同一个东西这块后端小伙伴通常会写成AES/CBC/PKCS5Padding前端对应CBC Pkcs7就行。2. 动手前先把环境和参数备齐2.1 安装与模块化引入Vue3 / React / 原生都适用先装依赖一条命令npm install crypto-js # 如果你用的是 yarn # yarn add crypto-js装完之后在 Vue3 或 React 项目里建议单独建一个src/utils/crypto.js不要在每个页面里散落引入 CryptoJS这样后续换算法或换库时只需要改一个文件。crypto-js 支持两种引入方式按需导入和全量导入// 按需引入只引入 AES 相关模块打包体积更小 import CryptoJS from crypto-js/core import crypto-js/cipher-core import crypto-js/aes import crypto-js/mode-cbc import crypto-js/pad-pkcs7 // 或者简单粗暴直接全量引入 // import CryptoJS from crypto-js如果你用的是 Vite 或 Webpack全量引入也不会有什么问题就是打包体积会多几十 KB。对于对包体积敏感的项目推荐按需引入。但我个人在实际项目中一般直接全量引入因为 crypto-js 的 Tree Shaking 在部分构建工具里并不总是生效按需引用的路径有时候反而会踩坑得不偿失。2.2 密钥和 IV 怎么定才不会被后端当“外行”这是前后端联调时最容易“掐架”的地方。密钥和 IV 本质上是一串字节序列但大家写代码时的表达方式五花八门关于怎么统一我总结了一个能用的方案密钥由后端生成一个 32 字节的字符串推荐用 Base64 或 Hex 格式传输给前端。你拿到的可能是a2V5LWZvci1mcm9udGVuZC0yMDI0LTEy这样的字符串也可能是6d797365637265742d6b65792d616573323536这种十六进制串。无论后端给你哪种格式在前端拿到之后都要用 CryptoJS 的 enc 方法先转成 WordArray 再传给 AES 函数。这一点非常重要因为 CryptoJS.AES.encrypt 的第一个参数如果直接传普通字符串CryptoJS 会先对密钥做一次 MD5 散列处理生成一个固定长度的 Key这会让你的密钥被悄悄“改掉”而后端不知道这个逻辑解密必然失败。IV 固定 16 字节一般由前后端约定一个固定字符串或者每次请求随机生成后随密文一起传到后端。前者简单后者更安全。考虑到调试方便我通常建议固定 IV业务上如果对安全性要求更高再升级为动态 IV。下面是一份可以直接对齐的示例参数参数推荐值说明算法AES-256密钥 32 字节模式CBC需要 16 字节 IV填充Pkcs7对应 Java 的 PKCS5Padding密钥编码Utf8 / Hex / Base64前后端必须一致输出编码Base64方便 JSON 传输2.3 后端配合的事项先对齐协议再写代码我踩过一个比较深的坑前端加密做完了后端 Java 接口怎么都解不出正确明文最后排查了两小时发现是后端用getBytes()获取密钥字节时默认字符集和前端约定不一致。所以写代码之前一定先把协议对齐不要上来就闷头写。需要对齐的点有这几个字符集统一用 UTF-8不要用平台默认字符集。密钥和 IV 的格式要明确是用字符串还是 Base64后端解密时用同一个 decode 方法。密文传输格式统一成 Base64后端拿到的字符串里不能有多余的换行符或空格。填充算法对齐前端 Pkcs7 对应 Java PKCS5Padding名字不同实际是同一个机制。加密数据的范围要约定清楚是整个 body 加密还是只加密里面的某几个字段。这会影响前端的封装方式和后端的解析逻辑。建议直接写进接口文档的“安全约定”章节两端照着同一份文档开发能少吵很多架。3. 核心实现一套可以直接抄的加解密封装3.1 加密函数封装含对象序列化与 Base64 输出我一般在项目里封装一个encrypt.js对外只暴露 encrypt 和 decrypt 两个方法业务代码不感知加密细节。加密函数的完整实现如下import CryptoJS from crypto-js // 密钥和 IV 从环境变量读取 // Vite 项目使用 import.meta.env.VITE_APP_CRYPTO_KEY // Vue CLI / Webpack 项目使用 process.env.VUE_APP_CRYPTO_KEY const KEY CryptoJS.enc.Utf8.parse(请从环境变量读取32字节密钥字符串) const IV CryptoJS.enc.Utf8.parse(16字节固定IV值) /** * AES-CBC-Pkcs7 加密 * param {*} data 支持任意 JSON 可序列化数据 * returns {string} Base64 密文 */ export function aesEncrypt(data) { // 统一转成 JSON 字符串避免传对象时出现 [object Object] const payload typeof data string ? data : JSON.stringify(data) const encrypted CryptoJS.AES.encrypt(payload, KEY, { iv: IV, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }) return encrypted.toString() }这里有几个细节值得展开。toString() 方法返回的是 OpenSSL 格式的 Base64 字符串其中包含加密数据本身可以直接传给后端。后端收到后一般会用 Base64 decode然后取出密文部分来做 AES 解密所以前端不用额外拼接 Salt 等元信息。另一个细节是序列化时机。我见过一些代码直接把对象传给 CryptoJS.AES.encrypt虽然 CryptoJS 内部会尝试把对象转成字符串但嵌套对象或者带特殊符号的内容很容易搞出怪问题。统一JSON.stringify之后再加密最大的好处是后端解密后可以直接用 JSON.parse 还原成对象少一层沟通成本。3.2 解密函数封装含异常兜底与空值处理解密函数比加密函数更需要做防御性处理因为加密是自己写的解密要面对的是后端返回的各种意外状况。我的实现是这样的/** * AES-CBC-Pkcs7 解密 * param {string} ciphertext Base64 密文 * returns {*} 解密后 JSON 解析的结果 */ export function aesDecrypt(ciphertext) { if (!ciphertext) return null try { const bytes CryptoJS.AES.decrypt(ciphertext, KEY, { iv: IV, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }) const result bytes.toString(CryptoJS.enc.Utf8) if (!result) { console.warn(解密结果为空请检查密钥或密文是否有效) return null } // 如果明文是 JSON 结构转成对象不是则直接返回字符串 try { return JSON.parse(result) } catch (e) { return result } } catch (error) { console.error(解密失败:, error) return null } }解密失败的时候CryptoJS.AES.decrypt 不一定会抛异常更多时候是返回一个空对象toString 出来是空字符串。如果发现解密结果是空的第一反应应该是去核对密钥、IV、密文三者的格式是否一致而不是怀疑加密算法写错了。JSON.parse的双层 try 结构也是一个小技巧。后端有些响应字段本身就是普通字符串强行 JSON.parse 会抛错所以第一次解析失败时直接返回原始字符串这样调用方不用关心底层数据形态。3.3 与 Java 后端的互通验证全流程前端封装写得再好如果和后端对不上一切白搭。我整理了一个完整的前后端互通方案两边照着写就能跑通。后端 Java 核心代码大致是这样import javax.crypto.Cipher; import javax.crypto.spec.IvParameterSpec; import javax.crypto.spec.SecretKeySpec; import java.nio.charset.StandardCharsets; import java.util.Base64; public class AesUtil { // 与前端的 KEY_STRING 保持一致 private static final String KEY_STRING 32字节的密钥字符串; private static final String IV_STRING 16字节的IV字符串; public static String encrypt(String plainText) throws Exception { SecretKeySpec keySpec new SecretKeySpec( KEY_STRING.getBytes(StandardCharsets.UTF_8), AES); IvParameterSpec ivSpec new IvParameterSpec( IV_STRING.getBytes(StandardCharsets.UTF_8)); Cipher cipher Cipher.getInstance(AES/CBC/PKCS5Padding); cipher.init(Cipher.ENCRYPT_MODE, keySpec, ivSpec); byte[] encrypted cipher.doFinal(plainText.getBytes(StandardCharsets.UTF_8)); return Base64.getEncoder().encodeToString(encrypted); } public static String decrypt(String cipherText) throws Exception { SecretKeySpec keySpec new SecretKeySpec( KEY_STRING.getBytes(StandardCharsets.UTF_8), AES); IvParameterSpec ivSpec new IvParameterSpec( IV_STRING.getBytes(StandardCharsets.UTF_8)); Cipher cipher Cipher.getInstance(AES/CBC/PKCS5Padding); cipher.init(Cipher.DECRYPT_MODE, keySpec, ivSpec); byte[] decrypted cipher.doFinal(Base64.getDecoder().decode(cipherText)); return new String(decrypted, StandardCharsets.UTF_8); } }前端对应const key CryptoJS.enc.Utf8.parse(32字节的密钥字符串) const iv CryptoJS.enc.Utf8.parse(16字节的IV字符串) // 加密 hello world const ciphertext CryptoJS.AES.encrypt(hello world, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }).toString() // 解密后应该得到 hello world const bytes CryptoJS.AES.decrypt(ciphertext, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }) const plaintext bytes.toString(CryptoJS.enc.Utf8)很多前端在联调时反复失败最大的原因就是忽略了CryptoJS.enc.Utf8.parse。如果直接把密钥字符串传进 AES 方法CryptoJS 会自作主张对密钥做 MD5 派生而后端完全没有这个机制。所以我在代码里特意把 parse 这一步拎出来就是为了防止这种隐蔽的坑。4. 上线后踩过的坑几个高频问题实录4.1 解密出来全是空字符串大概率是 IV 没对齐这个可以说是 AES 联调中排名第一的经典问题。前端明明加密成功后端也能拿到密文但解密结果就是空字符串。我排查了三次这类问题最后定位到的基本都是 IV 或者密钥的字节没对齐。比如前端定义 IV 是0123456789abcdef后端同学可能图省事直接IV 1234567890abcdef一个字符的差异就会导致解密结果乱码或为空。更隐蔽的是有些后端代码用了CryptoJS.enc.Base64.parse()来解析密钥而前端用的是Utf8.parse()两边字节内容完全不同但代码看起来还都是同一个字符串。排查建议是先分别在前端和后端打印密钥和 IV 的十六进制字节内容人工比对。如果字节对不上不要再看代码逻辑直接协商统一格式。4.2 中文乱码问题出在字符串编码加密英文和数字没什么问题一遇到中文就解密成火星文这是字符集没有统一的典型症状。前端JSON.stringify出来的字符串是 UTF-8 编码后端如果用 GBK 或其他字符集来 getBytes就会造成乱码。解决方式没有悬念前后端统一使用 UTF-8。前端在序列化和解析时明确使用 UTF-8 编码后端拿到密文后解密出的字节流用new String(decrypted, StandardCharsets.UTF_8)转换而不是用服务器默认字符集。另外提醒一下有些 HTTP 框架会在响应头里自动做字符集转换如果网关层出现过转码密文被改动了也会导致乱码。这时候可以在后端接口加一个针对加密字段的 Base64 解码日志看密文实时到达网关时是否和前端发送时一致。4.3 场景提醒不要把 Token 塞进明文里一起加密有一个安全问题值得单独提出来。有些团队为了省事把登录 Token、用户 ID、时间戳等全部塞进加密明文里交给后端。这种做法的风险在于一旦密钥泄露Token 跟着一起泄露前面所有的加密工作都白费了。更好的拆分方式是Token 放在 HTTP Header 里走标准鉴权流程AES 加密只负责保护 body 中的业务数据。这样做一方面符合前后端职责分离的惯例另一方面也方便后端在网关上做统一的 Token 校验不需要先解密 body 才能鉴权性能更好。4.4 面试被追问的前端加密是不是“脱裤子放屁”最后聊一个技术之外但很容易被问到的问题。前端密钥暴露在代码里所以前端加密不是“绝对安全”这种说法对不对对但不完整。加密的本质是提高攻击成本。如果你的系统里敏感数据可能以明文形式出现在日志、抓包工具、浏览器插件里那么 AES 加密至少能让这些常见泄露面变得无内容可看。真正的安全体系应该包括 HTTPS、权限控制、服务端加密存储、风控策略等多层防护前端加密是其中一层而不是全部。我个人的体会是不要神话前端加密也不要不屑于做前端加密。了解它的边界把它用在合适的位置比如敏感字段加密、防明文落日志、防参数篡改这就是它存在的价值。5. 还可以再进一步动态 IV 和 GCM 模式5.1 固定 IV 够用但动态 IV 更稳前面的封装里我用的固定 IV。固定 IV 的优点是简单、易于排查问题但同一个密钥配合固定 IV 加密相同明文会产生相同密文这在某些数据模式比较固定的场景中会暴露信息。如果你对安全性要求更高可以采用动态 IV 方案每次加密前生成一个随机的 16 字节 IV把 IV 拼接在密文前面然后一起 Base64 编码发送给后端。后端取出前 16 字节作为 IV剩下的部分作为密文去解密。这样相同的明文每次都生成不同的密文安全性提升一个档次。前端实现思路参考export function aesEncryptWithRandomIV(data) { const payload typeof data string ? data : JSON.stringify(data) // 生成随机 16 字节 IV const randomIv CryptoJS.lib.WordArray.random(16) const encrypted CryptoJS.AES.encrypt(payload, KEY, { iv: randomIv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }) // 把 IV 和密文拼一起统一 Base64 const combined randomIv.concat(encrypted.ciphertext) return CryptoJS.enc.Base64.stringify(combined) }后端对应处理Base64 解码后前 16 字节是 IV后面是密文。这种方案的缺点是需要后端多写一段拆分逻辑但只要习惯了收益很明显。5.2 后端要求 GCM 模式时怎么办有些安全团队会强制要求使用 AES-GCM 模式因为它自带完整性校验能防止密文被篡改。但 crypto-js 没有内置 GCM 模式这时候有两个选择一是使用 Web Crypto API。浏览器原生支持 AES-GCM性能比 crypto-js 更好但需要注意它是异步的。对于不支持 Web Crypto API 的老浏览器要做降级方案或直接拦截。二是使用stablelib/aes-gcm这类第三方库。它的体积更小API 设计也比较现代。不过需要后端的解密逻辑配合两边都要实现 GCM 模式的认证标签auth tag处理。我的建议是如果项目不强制要求 GCMCBC 模式加固定 IV 已经能满足绝大多数业务场景。如果一定要 GCM优先考虑 Web Crypto API因为它是浏览器标准能力未来兼容性更有保障。写在最后的几点实操心得把 crypto-js 的 AES 加解密落地到项目里不复杂但坑都在细节里。我踩过几次坑之后现在总结了一套自己的习惯密钥和 IV 统一从环境变量读取不写死在代码里加解密封装成独立工具函数业务层只调用 encrypt 和 decrypt项目启动时先写一个自测用例加密一段固定字符串解密回来能对得上再继续做其他功能。这种做法每次新建项目时都能节省大量联调时间。另外一个小技巧是在开发环境加一个日志开关把加密前的明文和解密后的明文都打印出来。正式环境关掉开发环境开着。一旦后端说解密失败你能立刻判断问题出在发送端还是接收端定位速度快很多。前端加密不是银弹但它确实能在很多实际场景中发挥作用。希望这篇文章能让你少走一些弯路把时间留给更有价值的事情。