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 作为基础防线，所有加密都建立在传输层已加密的前提下；否则中间人可篡改加密参数或降级攻击。真正安全是前后端策略一致、密钥生命周期可控、日志不落密文的组合结果。
