HTML5不提供直接加密AJAX的API,需结合Web Crypto API(如AES-GCM、RSA-OAEP)与后端协同实现:前端加密请求体、后端解密验证,密钥动态下发且不硬编码,全程依托HTTPS。

HTML5 本身不提供直接加密 AJAX 请求数据的 API,加密需结合 JavaScript 加密库与后端协同完成。核心思路是:在发送前对请求体(如 JSON 数据)做对称或非对称加密,服务端解密后再处理;敏感字段(如密码、token)绝不明文传输。
前端加密:选择合适算法 + 客户端实现
推荐使用成熟、轻量、Web 原生支持的加密方式:
- AES-GCM(推荐):现代对称加密,支持加密+认证,可直接用 Web Crypto API 实现(无需引入第三方库),密钥需安全派发(如登录后由后端动态下发)
- RSA-OAEP:适合加密小数据(如 AES 会话密钥),常用于“混合加密”——用 RSA 加密 AES 密钥,再用 AES 加密实际请求数据
- 避免使用已淘汰算法(如 MD5、SHA-1、DES、ECB 模式 AES)
密钥管理:不硬编码、不暴露、有时效
密钥是加密体系的安全命脉,必须规避常见错误:
- 前端代码中禁止写死密钥(会被反编译/调试轻易获取)
- 首次通信可走 HTTPS 明文登录,成功后由后端返回临时 AES 密钥(带过期时间、绑定 session 或设备指纹)
- 敏感操作(如支付、改密)可要求二次动态密钥(如短信/OTP 触发生成单次密钥)
- Web Crypto 生成的密钥建议标记
extractable: false,防止被导出
请求封装:统一拦截 + 自动加解密
借助 Fetch API 或 Axios 拦截器,避免每个接口重复写加密逻辑:
立即学习“前端免费学习笔记(深入)”;
- 请求发出前:序列化 data → 用当前有效密钥 AES 加密 → Base64 编码 → 放入 body(如
{encrypted: "..."}) - 响应到达后:检查是否含
encrypted:true→ 解密 response.body → 替换为原始 JSON 数据供业务层使用 - 在 header 中添加自定义字段标识加密版本(如
X-Enc: aes-256-gcm-v1),便于后端路由解密策略
后端配合:解密验证 + 防重放
前端加密只是半程,后端必须严格配套:
- 收到加密请求后,先校验 timestamp + nonce(防重放),再用对应密钥解密
- 拒绝无 timestamp / 超时(如 > 30s)、重复 nonce 的请求
- 解密失败直接 400,不泄露错误细节(避免侧信道攻击)
- 敏感响应(如用户信息)也可选择性加密返回,但需权衡性能与必要性
不复杂但容易忽略:全程依赖 HTTPS 作为基础防线,所有加密都建立在传输层已加密的前提下;否则中间人可篡改加密参数或降级攻击。真正安全是前后端策略一致、密钥生命周期可控、日志不落密文的组合结果。










