HTML5不提供数据加密能力，加密必须由服务端完成；前端可配合密钥管理与解密，但密钥不得硬编码，须通过HTTPS安全信道动态获取，并依托Web Crypto API安全解密，HTTPS是所有加密落地的基础保障。
HTML5 本身不提供接口响应数据加密能力，它只是前端运行环境；真正的加密必须在服务端完成，前端可配合做密钥管理、加解密操作或传输层保护。关键在于“谁来加密”和“怎么安全传递”。
服务端加密是核心前提
浏览器无法保证加密过程不被调试或篡改，所有敏感数据（如用户信息、token、支付结果）必须由后端生成响应前完成加密。常见做法：
- 使用 AES、RSA 或国密 SM4/SM2 对响应体整体或关键字段加密
- 加密密钥绝不硬编码在前端，应通过安全信道（如 HTTPS + 动态密钥分发）获取
- 服务端返回加密后的 base64 字符串，并附带算法标识、IV（如需）等元信息
前端可用 Web Crypto API 做轻量级解密
现代浏览器支持 Web Crypto API，可在客户端安全解密（仅限已知密钥且可信来源的场景）：
- 用
crypto.subtle.importKey()导入对称密钥（如从服务端动态获取的 AES 密钥） - 调用
crypto.subtle.decrypt()解密响应中的密文字段 - 注意：密钥不能明文写死，建议结合 Token 换取短期有效密钥，或使用 Diffie-Hellman 协商会话密钥
HTTPS 是加密落地的基础保障
即使服务端未加密响应内容，也必须启用 HTTPS：
立即学习“前端免费学习笔记（深入）”；
- 防止中间人窃听、篡改明文接口响应
- 为后续密钥交换（如 JWT 加密传输、密钥协商）提供可信通道
- 避免混合内容警告，确保 Web Crypto 等安全 API 正常启用（部分 API 仅在安全上下文生效）
避免常见误区
这些做法看似“加密”，实则无效或引入风险：
- 前端 JS 自实现 AES 加密再发请求：密钥暴露，算法可逆，毫无安全性
- 用 localStorage 存密钥或解密后明文缓存敏感数据：易被 XSS 窃取
- 只加密 URL 参数而忽略响应体：关键数据仍在响应中明文传输
- 用 Math.random() 或 Date.now() 生成密钥：熵值不足，不可用于密码学场景
