WebSocket如何保证通信的安全性？

1. 传输层加密（WSS）

在生产环境中，必须始终使用WSS（WebSocket Secure）协议，即在WebSocket连接上添加TLS/SSL加密层。WSS的工作原理与HTTPS类似：客户端先与服务器建立TLS握手，协商加密算法和会话密钥，然后在加密通道上发送WebSocket握手请求。这样，后续所有的WebSocket帧数据都会经过加密后再传输，有效防止中间人攻击（MitM）和数据窃听。现代浏览器要求HTTPS页面中只能创建WSS连接，而不能创建WS连接（混合内容策略）。根据OWASP 2026年最新指南，建议使用TLS 1.3协议和AEAD 算法（如TLS_AES_128_GCM_SHA256或TLS_CHACHA20_POLY1305_SHA256），并启用完美前向保密（PFS）以确保即使服务器私钥泄露，之前的会话也无法被解密。

2. 身份验证与授权

WebSocket 协议本身没有定义身份验证机制，通常需要在握手阶段集成现有的认证方案。常见的做法包括：在握手请求的URL参数中携带令牌（如wss://example.com/ws?token=xxx，但需注意URL参数可能出现在Nginx日志、CDN缓存或Referer头中，存在泄露风险）、使用HTTP Cookie（需设置Secure和SameSite属性）、在请求头中携带Authorization Bearer令牌（需要在升级前的HTTP请求中设置）。服务端在调用accept()接受WebSocket连接前，必须先验证令牌的合法性和有效期。对于长连接场景，建议每30分钟重新验证用户会话，确保会话仍然有效。

3. 输入验证与消息内容安全

即使握手阶段完成了身份认证，服务端也不能信任客户端发送的任何消息内容。所有接收到的WebSocket消息（无论是文本帧还是二进制帧）都必须进行严格的输入验证：检查消息格式是否符合预期、字段值是否在合法范围内、是否包含恶意构造的数据。对于文本帧，需要先验证UTF-8合法性，再解析JSON ；对于二进制帧，需要限制最大长度（如1MB），防止恶意客户端发送超大消息导致内存耗尽。此外，还需要对消息内容进行转义处理，防止跨站脚本攻击（XSS）。根据OWASP 2026年指南，应该对每条消息都进行授权检查，而不是仅在握手阶段认证一次就信任所有后续消息。