前端请求响应加密怎么做才安全？

UI淑然提问于 2026-03-17 12:10:28 阅读 46

安全

我最近在做登录接口，后端要求所有请求和响应都要加密，但我试了 AES 加密后发现密钥放前端根本藏不住，这不等于白加密吗？

我看到有些项目用 HTTPS 就行了，但后端坚持要应用层再加密一层。有没有既安全又可行的方案？总不能让用户自己输密钥吧……

顺便贴一下我测试时写的样式，虽然和加密无关，但怕影响整体结构：

.secure-form {
  padding: 16px;
  border: 1px solid #e0e0e0;
  border-radius: 8px;
  background: #f9f9f9;
}
.secure-form input {
  width: 100%;
  padding: 8px;
  margin: 4px 0;
}

我来解答赞 9 收藏

反馈

2 条解答

シ晶晶 Lv1

你提到的这个问题确实挺头疼的。前端加密的一大难题就是密钥管理，放在前端基本等于公开了。HTTPS 已经能保证传输过程的安全性，再加一层应用层加密意义不大，而且增加了复杂度。不过既然后端坚持，那我们得想办法。

一个常见的做法是使用对称加密结合非对称加密。具体步骤如下：

1. 后端生成一对公钥和私钥。
2. 公钥发给前端，前端用来加密数据。
3. 前端生成一个随机的对称密钥，用于实际的数据加密。
4. 使用从后端获取的公钥对这个对称密钥进行加密。
5. 把加密后的对称密钥和实际数据一起发送给后端。
6. 后端用自己的私钥解密对称密钥，然后再用这个对称密钥解密数据。

这样即使前端代码被看到，攻击者也无法轻易解密数据。下面是简单的示例代码：

const crypto = require('crypto');

const NodeRSA = require('node-rsa');



// 假设这是后端的公钥

const publicKey = '-----BEGIN PUBLIC KEY-----nMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqGKukO1De7zhZj6+H0qtjTkVxwTCpvKe4eCZ0FPqri0cb2JZfXJ/DgYSF6vUpwmJG8wVQZKjeGcjDOL5UlsuusFncCzWBQ7RKNUSesmQRMSGkVb1/3j+skZ6UtW+4u09lH9yGLFhEobrUw69N94gjSinX8YBwhfwpAEAcV0FX4ZpWQIDAQABn-----END PUBLIC KEY-----';



// 前端生成对称密钥

const symmetricKey = crypto.randomBytes(32);



// 使用公钥加密对称密钥

const key = new NodeRSA(publicKey);

const encryptedSymmetricKey = key.encryptPublic(symmetricKey, 'base64');



// 假设这是你要发送的数据

const data = 'your sensitive data here';



// 使用对称密钥加密数据

const cipher = crypto.createCipheriv('aes-256-cbc', symmetricKey, crypto.randomBytes(16));

let encryptedData = cipher.update(data, 'utf8', 'base64');

encryptedData += cipher.final('base64');



// 发送加密后的对称密钥和数据到后端

console.log('Encrypted Symmetric Key:', encryptedSymmetricKey);

console.log('Encrypted Data:', encryptedData);

这段代码展示了如何生成随机对称密钥并使用公钥加密，然后用对称密钥加密数据。后端需要反向操作来解密数据。希望这个方案能帮到你，效率更高，也更安全。

2026-03-20 17:06

Code°梓轩 Lv1

你这个问题很常见，很多人都会踩坑。直接说结论：在已经有 HTTPS 的情况下，应用层再加密一层其实意义有限，但如果你后端非要这么做，可以用动态密钥的方案。

核心问题就是你说的，密钥放前端怎么都藏不住，再怎么混淆都能被扣出来。

解决方案其实不复杂：用后端的公钥加密一个随机生成的对称密钥，每次请求时动态生成。流程是这样的：

1. 后端生成一对 RSA 公钥私钥，公钥直接丢前端（这个泄露了没事）
2. 每次用户登录或每次请求前，前端用 Web Crypto API 生成一个随机 AES 密钥
3. 用后端的公钥把这个 AES 密钥加密，发送给后端
4. 后端用私钥解密，得到 AES 密钥，然后用这个密钥加密响应返回给前端
5. 前端用同样的 AES 密钥解密

这样每次通信用的都是不同的临时密钥，即使前端代码被逆向，也只能拿到公钥，拿不到实际的会话密钥。

简单实现的话大概这样：

// 生成随机 AES 密钥

async function generateAesKey() {

  return await window.crypto.subtle.generateKey(

    { name: 'AES-GCM', length: 256 },

    true,

    ['encrypt', 'decrypt']

  );

}



// 用公钥加密 AES 密钥（需要把公钥导入为 CryptoKey）

async function encryptKeyWithPublicKey(aesKey, publicKeyJson) {

  const publicKey = await window.crypto.subtle.importKey(

    'jwk',

    publicKeyJson,

    { name: 'RSA-OAEP', hash: 'SHA-256' },

    false,

    ['encrypt']

  );

  

  const exportedKey = await window.crypto.subtle.exportKey('raw', aesKey);

  const encryptedKey = await window.crypto.subtle.encrypt(

    { name: 'RSA-OAEP' },

    publicKey,

    exportedKey

  );

  

  return Array.from(new Uint8Array(encryptedKey));

}

响应加密解密用 AES-GCM 模式，记得每次通信都要生成新的 IV。

不过说句实在话的，如果你们后端的安全需求不是特别变态（防内部人员那种），真没必要在应用层再套一层。HTTPS + 证书固定就已经够用了。应用层加密会增加前端计算负担，用户体验也会受影响，你们后端要是能沟通的话，建议再聊聊。

2026-03-17 19:01