简介这份源码资源面向需要实现前后端安全通信的Web开发者重点解决前端敏感数据在传输过程中易被截取的问题。资源以RSA非对称加密为核心前端借助jsencrypt库对数据进行公钥加密后端通过Java的RSAUtils工具类完成私钥解密形成一套可直接参考的加密解密闭环方案。压缩包共4个文件约54KB包含2个JavaScript文件、1个HTML页面和1个Java类分别承担前端加密逻辑、页面交互、后端解密处理等职责结构精简便于快速理解与移植。目前已有3167人学习下载说明该方案在实际开发中具有较高的参考价值。读者可从中掌握公钥私钥的生成与配置、Base64编码的PEM格式解析、Cipher加解密流程以及前后端数据交互的完整实现思路适合作为登录密码、支付信息等敏感字段加密传输的入门范例也可在此基础上扩展密钥管理与异常处理机制。1. 前后端加密联调一个登录请求从明文到密文的完整链路做过登录注册的都知道前端把密码明文往接口里一扔浏览器控制台一抓包就全看见了。之前接手一个后台管理系统安全扫描直接报了个高危——请求体里的密码字段是裸的。改法其实不复杂前端用 jsencrypt 把敏感字段加密后端用 Java 的 RSA 私钥解密。这套源码就是干这个的一份能直接跑起来的前后端加密解密 Demo前端 JavaScript 负责公钥加密后端 Java 负责私钥解密中间靠一对 RSA 密钥串起来。它适合谁正在做登录、支付、改密这类敏感表单又不想上整套 HTTPS 双向认证那么重的场景。也适合刚接触非对称加密、想找个能跑通的例子把 RSA 搞明白的开发者。整份源码不依赖复杂框架前端一个 jsencrypt 库后端一段 Java 工具类拿来就能往自己项目里塞。2. 技术选型拆解为什么是 jsencrypt 配 Java RSA2.1 非对称加密在这个场景里解决了什么对称加密比如 AES速度快但有个死结密钥怎么给到前端。你把 AES 密钥写在前端代码里等于没加密谁都能扒出来。非对称加密正好绕开这个问题——公钥可以随便公开前端拿公钥加密只有后端手里的私钥能解开。前端就算被人扒了源码拿到的也只是公钥解不出任何东西。RSA 是最常见的非对称算法实现。这套源码选它核心原因就一个Java 标准库java.security里自带 RSA 支持不用引第三方加密包前端 jsencrypt 又是纯 JS 实现的 RSA不依赖 Node 环境浏览器直接跑。两边对 RSA 的填充模式PKCS#1 v1.5默认兼容联调时少踩很多格式坑。常见做法是后端生成一对密钥公钥给前端私钥自己留着。密钥长度一般选 1024 或 2048 位。1024 位现在偏弱但加密一个短密码字段够用2048 位更稳代价是密文更长、加解密稍慢。这份源码里两种都能改后面讲参数时会说怎么切。2.2 前端 jsencrypt 的定位和引入方式jsencrypt 是个老牌库API 极简核心就三个方法setPublicKey、encrypt、decrypt。前端只用前两个。它的加密结果是 Base64 字符串正好能塞进 JSON 请求体不用再做额外编码。引入方式有两种。一种是 script 标签直接引!-- 引入 jsencrypt注意放在业务脚本之前 -- script srcjsencrypt.min.js/script script // 页面加载后初始化加密对象 var encryptor new JSEncrypt(); // 设置后端下发的公钥PEM 格式字符串 encryptor.setPublicKey(publicKey); /script另一种是 npm 装包后 import适合 Vue/React 工程// 工程化项目里按模块引入 import JSEncrypt from jsencrypt; const encryptor new JSEncrypt(); encryptor.setPublicKey(publicKey); const encrypted encryptor.encrypt(myPassword123);两种方式效果一样。script 标签适合老项目快速接入npm 适合现代构建工具。注意encrypt方法在加密失败时返回false而不是抛异常所以调用后一定要判空这点后面避坑章节会细说。2.3 后端 Java RSA 的依赖情况后端这块源码用的是 JDK 自带的javax.crypto和java.security没有引 BouncyCastle 之类的第三方库。核心类就两个KeyPairGenerator生成密钥对Cipher做加解密。这意味着你只要有个 JDK 8 以上的环境就能跑不用改 pom 或 build.gradle。密钥的存储方式源码里给了两种一种是硬编码在配置里仅限本地调试一种是从文件读取 PEM。生产环境肯定用后者私钥文件权限设成只有应用进程能读。公钥可以随接口下发给前端也可以前端写死——写死的问题是换密钥要重新发版所以更推荐后端提供一个/getPublicKey接口动态下发。3. 核心模块拆解密钥生成、前端加密、后端解密三段链路3.1 后端密钥对生成与公钥下发先看密钥怎么来。源码里有个RsaKeyUtil工具类负责生成密钥对并输出 Base64 编码的公私钥字符串import java.security.KeyPair; import java.security.KeyPairGenerator; import java.security.PrivateKey; import java.security.PublicKey; import java.util.Base64; public class RsaKeyUtil { // 生成 RSA 密钥对keySize 建议 1024 或 2048 public static String[] generateKeyPair(int keySize) throws Exception { KeyPairGenerator generator KeyPairGenerator.getInstance(RSA); generator.initialize(keySize); // 初始化密钥长度 KeyPair keyPair generator.generateKeyPair(); PublicKey publicKey keyPair.getPublic(); PrivateKey privateKey keyPair.getPrivate(); // 用 Base64 编码方便存文件和网络传输 String pub Base64.getEncoder().encodeToString(publicKey.getEncoded()); String pri Base64.getEncoder().encodeToString(privateKey.getEncoded()); return new String[]{pub, pri}; } }逻辑说明KeyPairGenerator.getInstance(RSA)拿到 RSA 密钥生成器initialize(keySize)指定长度。生成后getPublic()和getPrivate()分别拿到公私钥对象再用getEncoded()转成字节数组Base64 编码成字符串。返回数组第一个是公钥第二个是私钥。参数说明keySize传 1024 或 2048。1024 位加密短字符串够用密文 Base64 后约 172 字符2048 位密文约 344 字符。如果你的敏感字段很长比如整段 JSONRSA 单次加密有长度上限1024 位最多加密 117 字节2048 位最多 245 字节超了要分段或改用混合加密。公钥下发接口一般这么写// 控制器里暴露公钥前端启动时拉一次 GetMapping(/getPublicKey) public String getPublicKey() { // 从配置或文件读取公钥字符串 return rsaConfig.getPublicKey(); }前端拿到后setPublicKey即可。注意公钥字符串不要带 PEM 的头尾标记-----BEGIN PUBLIC KEY-----jsencrypt 要的是纯 Base64 内容带了标记会加密失败。3.2 前端加密函数与请求封装前端核心就一个加密函数包一层方便复用// 加密工具函数传入明文返回密文失败返回 null function rsaEncrypt(plainText) { var encryptor new JSEncrypt(); encryptor.setPublicKey(window.publicKey); // 公钥由后端下发 var cipher encryptor.encrypt(plainText); if (!cipher) { console.error(RSA 加密失败检查公钥格式); return null; } return cipher; } // 登录请求里只加密密码字段 function login(username, password) { var encryptedPwd rsaEncrypt(password); if (!encryptedPwd) return; fetch(/api/login, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ username: username, password: encryptedPwd }) }); }逻辑说明每次加密新建一个JSEncrypt实例设置公钥后调encrypt。返回false说明公钥有问题或明文超长这里判空并打日志。登录函数里只加密密码用户名保持明文——用户名不算敏感信息全加密反而增加后端负担。参数说明plainText是要加密的字符串中文和特殊字符都支持jsencrypt 内部会先做 UTF-8 编码。window.publicKey是页面初始化时从后端拉的公钥。如果你的项目用 axios把encryptedPwd塞进请求体即可逻辑一样。3.3 后端解密工具类与接口接入后端解密是重头戏源码里的RsaDecryptUtilimport javax.crypto.Cipher; import java.security.KeyFactory; import java.security.PrivateKey; import java.security.spec.PKCS8EncodedKeySpec; import java.util.Base64; public class RsaDecryptUtil { // 用私钥解密前端传来的 Base64 密文 public static String decrypt(String cipherText, String privateKeyStr) throws Exception { // 1. Base64 解码私钥字符串 byte[] keyBytes Base64.getDecoder().decode(privateKeyStr); PKCS8EncodedKeySpec keySpec new PKCS8EncodedKeySpec(keyBytes); KeyFactory keyFactory KeyFactory.getInstance(RSA); PrivateKey privateKey keyFactory.generatePrivate(keySpec); // 2. 初始化解密器模式必须和前端一致 Cipher cipher Cipher.getInstance(RSA/ECB/PKCS1Padding); cipher.init(Cipher.DECRYPT_MODE, privateKey); // 3. Base64 解码密文后解密 byte[] cipherBytes Base64.getDecoder().decode(cipherText); byte[] plainBytes cipher.doFinal(cipherBytes); return new String(plainBytes, UTF-8); } }逻辑说明第一步把私钥字符串还原成PrivateKey对象PKCS8EncodedKeySpec对应 PKCS#8 格式的私钥。第二步Cipher.getInstance指定算法和填充模式这里RSA/ECB/PKCS1Padding必须和前端 jsencrypt 的默认模式对上否则解密出来是乱码或直接抛异常。第三步先 Base64 解码密文再doFinal解密最后按 UTF-8 转字符串。参数说明cipherText是前端传来的 Base64 密文privateKeyStr是 Base64 编码的私钥。注意Cipher.getInstance的写法有些环境写RSA也能跑但显式写全RSA/ECB/PKCS1Padding更稳避免不同 JDK 默认填充不一致。接口里接入PostMapping(/login) public Result login(RequestBody LoginDTO dto) throws Exception { // 解密前端传来的密码 String rawPassword RsaDecryptUtil.decrypt(dto.getPassword(), rsaConfig.getPrivateKey()); // 后续走正常的密码校验逻辑 return userService.checkLogin(dto.getUsername(), rawPassword); }这样前端密文进、后端明文出业务层完全不用感知加密的存在。4. 跑起来环境准备、密钥配置与联调验证4.1 环境与依赖清单跑这套源码环境要求不高组件版本要求说明JDK8 及以上用自带加密库无需额外依赖前端浏览器支持 ES5 即可jsencrypt 兼容性很好构建工具Maven 或 Gradle后端打包用前端引入jsencrypt.min.js本地文件或 CDN 均可后端不需要引任何加密相关的第三方包这点很省心。前端把jsencrypt.min.js放到静态资源目录页面里 script 引一下就行。4.2 生成密钥并配置到前后端第一步跑一次密钥生成拿到公私钥字符串。可以写个 main 方法public static void main(String[] args) throws Exception { String[] keys RsaKeyUtil.generateKeyPair(1024); System.out.println(公钥 keys[0]); System.out.println(私钥 keys[1]); }把输出的公钥配到后端下发给前端的接口里私钥配到后端解密用的配置里。前端页面加载时调/getPublicKey拿到公钥存到window.publicKey。提示公私钥必须成对使用换了一个另一个也要换。调试时如果解密失败先确认这对密钥是不是同一次生成的。4.3 联调验证从抓包看密文到后端断点看明文验证分三步。第一步浏览器 F12 打开 Network提交登录请求看请求体里 password 字段是不是一长串 Base64 密文。如果是明文说明前端加密没生效检查公钥是否设置成功。第二步后端在decrypt方法里打断点看传入的cipherText和返回的明文。明文应该和前端输入的原始密码一致。第三步故意改错一个字符再提交后端应该抛解密异常。这一步是确认加密链路真的在起作用而不是碰巧跑通。常见做法是写个单元测试固定验证Test public void testEncryptDecrypt() throws Exception { String[] keys RsaKeyUtil.generateKeyPair(1024); // 模拟前端加密这里用 Java 公钥加密代替 jsencrypt String cipher RsaEncryptUtil.encrypt(test123, keys[0]); String plain RsaDecryptUtil.decrypt(cipher, keys[1]); assertEquals(test123, plain); }这样不依赖浏览器就能验证后端加解密逻辑自洽。5. 避坑与排查联调时最容易翻车的五个点5.1 加密返回 false 却没人发现现象前端提交后后端报解密失败但前端控制台没有任何报错。原因jsencrypt 的encrypt方法失败时返回布尔值false不抛异常很多人直接把这个false塞进请求体后端收到字符串 false 去解密自然失败。解决加密后必须判空if (!cipher) return;并在控制台打日志。我一般会封装一层失败直接阻断请求。5.2 公钥带了 PEM 头尾导致加密失败现象公钥明明是对的setPublicKey之后encrypt就是返回 false。原因从文件读出来的公钥带了-----BEGIN PUBLIC KEY-----和-----END PUBLIC KEY-----标记jsencrypt 只认中间的纯 Base64 内容。解决下发前把头尾和换行符去掉只留 Base64 字符串。后端读取 PEM 文件时也要做同样的清洗。5.3 填充模式不一致解密出乱码现象后端能解密不报错但解出来的明文是乱码。原因前端 jsencrypt 默认用 PKCS#1 v1.5 填充后端Cipher.getInstance(RSA)在某些 JDK 上默认填充不同。解决后端显式写RSA/ECB/PKCS1Padding和前端对齐。这个坑很隐蔽因为不报错只是结果不对。5.4 明文超长导致加密截断现象短密码能加密长一点的字符串加密后解密失败或内容不全。原因RSA 单次加密有长度上限1024 位密钥最多加密 117 字节超了 jsencrypt 会返回 false 或截断。解决敏感字段控制在长度限制内如果确实要加密长内容改用 AES 加密内容、RSA 加密 AES 密钥的混合方案。这套源码只适合短字段。5.5 密钥硬编码进了代码仓库现象本地跑得好好的一上线就出问题或者安全扫描报警。原因调试时图省事把私钥硬编码在代码里提交到了仓库。解决私钥放配置文件或环境变量配置文件加进.gitignore。生产环境的私钥文件权限设成只有应用进程可读。这个坑属于血泪经验一旦私钥泄露整套加密形同虚设。6. 二次开发把加密逻辑抽成可复用组件的改造思路源码跑通之后真正要落地到自己项目得做几处改造。第一处是把前端加密抽成一个独立模块不要散落在各个请求里。我一般会写一个crypto.js导出encryptField和encryptFields两个方法后者支持批量加密多个字段// 批量加密指定字段返回新对象 export function encryptFields(data, fields) { const result { ...data }; fields.forEach(key { if (result[key]) { const cipher rsaEncrypt(result[key]); if (cipher) result[key] cipher; } }); return result; }这样登录、改密、支付各个页面调同一个函数字段列表配一下就行改加密策略时只动一个文件。第二处是后端把解密做成注解或拦截器而不是每个接口手动调decrypt。常见做法是自定义一个RsaDecrypt注解标在需要解密的字段上配一个RequestBodyAdvice在请求体反序列化后自动解密。这样业务代码里看不到任何加密痕迹新增接口零成本接入。改造时注意一点自动解密只对标注的字段生效别全量解密否则用户名这种非敏感字段也走一遍 RSA白白增加开销。第三处是密钥轮换。生产环境密钥不能一直不换但换了之后前端缓存的旧公钥就失效了。我的做法是公钥接口返回里带一个版本号前端把公钥和版本号一起缓存请求时带上版本号后端发现版本不匹配就返回特定错误码前端收到后重新拉公钥再重试一次。这样轮换密钥时用户无感知。验证改造是否成功我习惯用三个检查点抓包看敏感字段是否密文、后端日志看解密是否成功、故意用旧公钥请求看是否正确触发重新拉取。从那以后我每次接入加密功能都强制走一遍这三个检查点再也没出现过上线才发现解密失败的情况。希望帮到你。本文还有配套的精品资源点击获取