客户端请求如何加密 日常维护方法与实用案例

你有没有想过，当你在手机上登录账号、提交订单或者发消息时，这些数据是怎么防止被别人偷看的？尤其是在公共Wi-Fi下，万一信息被截获，密码岂不是直接暴露了？其实，这背后靠的就是客户端请求的加密技术。

为什么需要加密客户端请求

想象一下你在咖啡馆用免费Wi-Fi查银行余额。如果你的请求没加密，网络中的其他人就可能通过工具抓包，看到你发送了哪些信息。而一旦请求被加密，即使被截获，对方看到的也只是一堆乱码。

HTTPS 是最基础的保护

现在大多数网站都用 HTTPS，它就是在 HTTP 的基础上加了一层 SSL/TLS 加密。当你访问一个 HTTPS 网站时，浏览器会先和服务器“握手”，协商出一套加密规则，之后所有的请求和响应都会被自动加密。

比如你访问 https://example.com/login 提交用户名密码，这个请求在传输过程中已经被 TLS 保护，中间人拿不到明文数据。

前端也可以主动加密敏感内容

有些场景下，仅靠 HTTPS 还不够。比如某些 App 或网页希望连服务器管理员都看不到用户的真实数据，这时就需要在客户端做额外加密。

常见的做法是使用 JavaScript 在提交前对关键字段加密。例如，登录时不对密码明文发送，而是先用 RSA 公钥加密：

const encryptedPassword = encryptRSA(password, publicKey);
fetch('/api/login', {
  method: 'POST',
  body: JSON.stringify({
    username: 'user123',
    password: encryptedPassword  // 发送的是密文
  })
});

这样即使请求被内部人员看到，也解不开密码内容，只有持有私钥的后端才能解密。

Token 和签名防篡改

除了加密，很多 API 请求还会加上签名机制。比如客户端在发请求前，用 secret 对参数做一次哈希，生成 signature，一起发出去：

const params = {
  action: 'transfer',
  amount: 100,
  timestamp: 1712345678
};

params.sign = md5(JSON.stringify(params) + 'my-secret-key');

fetch('/api/do', { method: 'POST', body: JSON.stringify(params) });

服务器收到后用同样的方式验证签名。如果请求被中途修改，签名就对不上，请求会被拒绝。这种方式不能防止窃听，但能防篡改。

混合加密更安全

实际项目中，通常会结合多种方式。比如先用 HTTPS 保证通道安全，再对身份证号、手机号等敏感字段用 AES 单独加密一次。

const sensitiveData = {
  idCard: '123456789012345678',
  phone: '13800138000'
};

const encryptedStr = aesEncrypt(JSON.stringify(sensitiveData), 'session-key');

fetch('/api/submit', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ data: encryptedStr })
});

这种方式即使未来 HTTPS 被降级攻击，核心数据仍有第二层保护。

别忘了密钥安全

加密的前提是密钥不泄露。如果把私钥或加密密钥直接写在前端代码里，等于把钥匙挂在门把手上。正确的做法是通过安全接口动态获取临时密钥，或依赖系统级安全模块（如 Android Keystore、iOS Keychain）来管理。

加密不是万能的，但它能大大提升攻击成本。对于普通用户来说，认准网址前的小绿锁图标，尽量避免在不可信网络下操作敏感事务，就已经能避开大多数风险了。