必须使用wss://协议并验证服务端证书，严格校验Origin、Cookie或签名token，配合CSP与HSTS等前端防护，杜绝中间人篡改。
防止 WebSocket 遭到中间人篡改攻击，核心是切断攻击者窥探、劫持或修改通信内容的可能性。关键不在于 WebSocket 协议本身怎么写，而在于连接建立前的传输通道是否可信、握手阶段是否可控、以及客户端与服务端之间是否存在信任链。
强制使用 wss:// 协议
WebSocket 明文协议 ws:// 与 HTTP 类似，所有数据（包括握手头、消息体）均以明文在网络中传输，极易被代理、Wi-Fi 热点或局域网设备截获和篡改。必须全程使用加密协议 wss://，它基于 TLS/SSL，在 TCP 层之上建立安全隧道。
- 服务端需部署有效的 HTTPS 证书（推荐 Let’s Encrypt 或商业 CA），并用
https.Server启动 Socket.IO 或原生 WebSocket 服务 - 前端连接时必须写死
wss://yourdomain.com，禁止拼接用户输入或环境变量生成 URL - 若通过 Nginx 反向代理，需确保 proxy_pass 指向后端
https://或本地http://时，Nginx 与后端之间也启用 TLS（可选但推荐）
验证服务端身份，禁用不安全证书策略
仅用 wss:// 不够——如果客户端忽略证书错误（如自签名、域名不匹配、过期），中间人仍可伪造服务端完成“合法”握手。
- 浏览器环境天然校验证书，无需额外操作；但 Electron、Cordova 或 WebView 场景下，务必禁用
webContents.session.setCertificateVerifyProc等绕过验证的逻辑 - 移动端 Hybrid App 若使用原生 WebSocket API，应调用系统级 TLS 校验（如 Android 的
SSLSocketFactory默认行为），不要手动 acceptAllCertificates - 开发阶段避免用
rejectUnauthorized: false（Node.js 客户端）或ssl.verify = false（某些 SDK），这类配置绝不能进入生产代码
在握手阶段绑定可信上下文
WebSocket 握手虽走 HTTP，但服务器无法默认识别用户身份。攻击者可在 TLS 通道内伪造 Origin 或 Cookie，冒充合法用户建立连接。
立即学习“前端免费学习笔记（深入）”；
- 服务端应在
upgrade事件或 Socket.IO 的handshake钩子中，严格校验req.headers.origin是否属于白名单（如['https://app.example.com', 'https://admin.example.com']） - 结合已有会话机制（如 Express session + signed cookie），在握手时读取并验证
req.headers.cookie，拒绝无有效 session 的连接请求 - 对高敏感场景（如金融类实时交易），可要求前端在 query 中携带短期有效的签名 token（如
wss://api.example.com?token=xxx），服务端用共享密钥验签后再放行
配合前端基础防护减少攻击面
中间人攻击常与其他漏洞协同利用。即使 WebSocket 本身加密，若页面被注入恶意脚本，攻击者仍可劫持 socket 实例、篡改发送/接收逻辑。
- 页面必须启用
Content-Security-Policy，限制 script-src 仅允许自身域名和可信 CDN，阻止外链 JS 注入 - 设置
Strict-Transport-Security（HSTS）响应头，强制浏览器后续所有请求走 HTTPS，避免降级到 ws:// - 敏感操作（如发送指令、确认交易）不在 WebSocket 上裸传关键字段，建议额外加签（如用 WebCrypto 对 payload 做 HMAC）并由服务端验签
