前端AES加密后数据在传输时还是被拦截了怎么办？

夏沫提问于 2026-02-11 21:37:24 阅读 25

安全

在表单提交时用AES加密了用户密码，但用抓包工具还是能看到明文数据，这正常吗？

我按网上的教程用了crypto-js写了个加密方法：


function encrypt(data) {
  return CryptoJS.AES.encrypt(data, 'my-secret-key', {
    mode: CryptoJS.mode.CBC,
    padding: CryptoJS.pad.Pkcs7
  }).toString();
}

然后在表单提交前调用了这个函数，但用Postman抓包时发现请求体里的密码还是明文。难道前端加密没生效？

已经试过把密钥改成环境变量，换了不同的加密模式，甚至把加密函数写在立即执行函数里，但问题依旧存在。是不是加密逻辑哪里漏了？

我来解答赞 4 收藏

反馈

1 条解答

宇文慧利 Lv1

你这个情况一点都不奇怪，前端加密没生效是因为你根本没在提交前真正替换掉原始数据。

看你的代码，encrypt 函数写得没问题，但问题大概率出在表单处理逻辑上：你可能对密码做了加密，但最后发请求的时候还是把原始 input 的 value 塞进了 payload，而不是用 encrypt 后的结果。比如像这样：

const password = document.getElementById('password').value;

const encrypted = encrypt(password);

// 错误示范：还是传了原始 password

fetch('/login', {

  method: 'POST',

  body: JSON.stringify({ password }) // 啊！这里应该传 encrypted

});

你应该确保发送的是 encrypt(password) 的返回值，而且最好检查下网络请求的实际 payload，在 DevTools 的 Network 选项卡里看请求体，别用 Postman 模拟，直接看浏览器发出的原始数据才准。

不过更要命的是，就算你现在修好了加密，AES 前端硬编码密钥也防不住多少攻击。攻击者照样能反编译 JS 拿到密钥解密，中间人还是能看到“密文”转成明文的过程。真想防止注入和窃取，光靠前端加密是自欺欺人。

正确的做法是：前端加密只能作为纵深防御的一环，核心必须配合 HTTPS 防止传输层被嗅探，后端再做一次解密校验。密钥别写死在代码里，可以通过接口动态获取，加点时间戳或随机盐，防止重放。

还有，别忘了 XSS 风险，如果页面被注入脚本，你加密前的明文密码照样会被截走。所以 CSP 策略、输入过滤、HttpOnly cookie 这些基本防护一个都不能少。

总结：先修逻辑错误，确保加密后的数据真正被提交；然后别依赖前端加密当救命稻草，HTTPS + 安全的后端验证才是正道。

2026-02-11 22:01