WebSocket连接需在握手阶段显式传递token验证身份，服务端解析并校验后绑定用户信息至socket实例，同时采取短期token、Origin校验等措施防范安全风险。
WebSocket 连接本身不携带 Cookie 或 HTTP 头，无法自动继承浏览器的 Session 信息，所以不能直接复用传统 HTTP 的 Session 验证机制。必须在建立连接时显式传递身份凭证，并在服务端完成验证。
WebSocket 握手阶段传参验证
客户端在创建 WebSocket 连接时，可通过 URL 查询参数或自定义请求头（仅限部分环境）传递 token 或 sessionId：
- 推荐方式：把 JWT 或短期有效的 session token 拼在 WebSocket URL 后，例如
ws://example.com/ws?token=abc123 - 服务端（如 Node.js + ws 库）在
connection事件中解析 query string，校验 token 有效性、签名和过期时间 - 避免传敏感信息（如密码、原始 sessionId）；token 应有签名、有效期和绑定用户标识
服务端关联 WebSocket 实例与用户身份
验证通过后，需将用户身份信息与当前 WebSocket 连接实例绑定，后续消息处理才能识别“谁发来的”：
- 维护一个 Map 或对象，以
socket.id（或自定义唯一标识）为键，存储用户 ID、角色、权限等上下文 - 不要依赖全局变量存用户信息；每个 socket 实例应独立持有其认证状态
- 连接关闭时及时清理映射关系，防止内存泄漏
避免会话劫持与重放攻击
单纯靠 URL 传 token 存在泄露风险（如被代理、日志记录），需配合其他防护措施：
立即学习“Java免费学习笔记（深入）”；
- Token 设为短期有效（如 5 分钟），并支持刷新机制（可结合 HTTP 接口实现）
- 服务端校验 Origin 头，限制合法域名发起 WebSocket 请求
- 对高敏感操作（如转账、删数据），不在 WebSocket 中直接执行，而是要求二次确认或跳转到带完整 Session 的 HTTP 接口
不推荐依赖 Cookie 自动带入
虽然浏览器会在 WebSocket 握手（HTTP Upgrade 请求）时自动带上同域 Cookie，但存在明显缺陷：
- 跨域场景下不可用（CORS 不控制 Cookie，但同源策略限制）
- 无法保证 Cookie 未被篡改，缺乏 token 的可验证性
- 服务端若只查 sessionStore，可能因集群部署导致 session 数据不同步而验证失败
本质是把身份验证前移到连接建立环节，而不是依赖连接后的状态延续。只要握手时验证可靠、连接生命周期内状态绑定清晰，就能安全支撑后续双向通信。
