WebSocket 本身不提供消息加密，wss://仅保障传输层安全，应用层需用 Web Crypto API 的 AES-GCM 实现端到端加密，并配合服务端统一协议、密钥动态下发与运行时防护。
HTML5 中 WebSocket 本身不提供消息内容加密能力，wss:// 只保障传输层安全（TLS 加密），但一旦 TLS 被绕过或终端被控制，明文消息仍可被读取。真正防窃听、防篡改，必须在应用层做二次加密——这是当前生产环境的通用做法。
用 Web Crypto API 实现端到端 AES-GCM 加密
现代浏览器原生支持 Web Crypto API，比引入第三方库更安全、无依赖、性能好。推荐使用 AES-GCM（带认证的对称加密），它同时保证机密性与完整性：
- 生成密钥：调用
window.crypto.subtle.generateKey("AES-GCM", true, ["encrypt", "decrypt"]) - 加密发送：用
encrypt()方法处理文本或 ArrayBuffer，传入随机 IV 和附加数据（如时间戳） - 解密接收：收到消息后，用相同密钥 + IV + 附加数据调用
decrypt()，失败即丢弃（GCM 自动校验） - 注意：密钥绝不硬编码，也不存 localStorage；建议由服务端动态下发，且绑定会话 ID 或短期 Token
前端加密需配合后端统一加解密协议
仅前端加密是单向的，服务端必须能同步解密并加密响应。关键点包括：
- 前后端约定一致的算法参数：AES-GCM 的 IV 长度（12 字节）、标签长度（16 字节）、盐值（如有）
- 消息结构标准化：例如采用 JSON 格式封装
{"iv":"base64","data":"base64","tag":"base64"}，避免解析歧义 - 敏感操作强制加密：登录态、用户 ID、金额、实时指令等字段必须加密；非敏感心跳帧可跳过以减小开销
- 服务端需校验解密后的附加数据（如时间戳是否超时、来源是否匹配），防止重放攻击
规避常见陷阱：密钥管理与运行时防护
90% 的前端加密失效，源于密钥暴露或逻辑被绕过：
立即学习“前端免费学习笔记（深入）”；
- 禁用 console.log 输出密钥或解密后明文；生产环境移除所有调试日志
- 不把密钥存在
localStorage、sessionStorage或全局变量中 - 避免在页面加载时一次性解密全部密钥；按需请求、短时内存驻留、用完清零（
crypto.subtle.importKey()后及时丢弃原始密钥材料） - 启用 Subresource Integrity（SRI）校验 CryptoJS 等外部脚本（若必须使用），防止 CDN 投毒
不要忽略连接层基础防护
应用层加密不能替代传输层加固：
- 强制使用
wss://，禁止 ws:// 上线；Nginx 或 CDN 层配置 TLS 1.3，禁用弱密码套件 - WebSocket 握手请求中添加自定义 Header（如
X-Auth-Token），服务端验证通过才升级连接 - 客户端校验服务器证书指纹（通过
WebSocket.onopen后发起一次轻量 HTTPS 请求比对），增强身份可信度 - 限制 WebSocket 连接来源：服务端检查
Origin头，只允许可信域名建立连接
