WebSocket 防范 CSRF 的核心是三重验证：校验 Origin 头、绑定用户会话、引入一次性 CSRF Token；需配合前端安全机制形成纵深防御。
WebSocket 本身不携带身份上下文，一旦连接建立，服务器就默认信任该通道——这正是 CSRF 攻击能得逞的关键。防范重点不是“阻止连接”，而是确保每个 WebSocket 握手请求确实来自合法用户、合法页面、合法意图。
验证 Origin 头是最基础且有效的防线
浏览器在发起 WebSocket 连接时会自动带上 Origin 请求头（如 Origin: https://yourapp.com），服务端必须校验它是否属于白名单域名。不能依赖 Referer（易被篡改或缺失），也不能放行通配符 *。
- 使用 gorilla/websocket 时，通过 CheckOrigin 函数实现，返回 true 才允许升级
- 在 Javalin 或 Spring Boot 中，可在 WebSocket 端点入口处读取并比对 ctx.header("Origin")
- 注意：本地开发时（如 http://localhost:3000）需单独加入白名单，生产环境严禁开放 localhost
强制绑定会话与 WebSocket 连接
Origin 只防跨域，不防同域下的恶意脚本。真正可信的身份确认，必须将 WebSocket 连接和用户已认证的会话关联起来。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 握手阶段（HTTP Upgrade 请求）检查 Cookie 或 Authorization Header，验证 session 是否有效
- Socket.IO 可结合 Passport.js 中间件，在 io.engine.use() 中拦截并拒绝未登录请求
- 若采用 Token 认证，要求客户端在 URL 查询参数（如 ?token=xxx）或 Sec-WebSocket-Protocol 字段中传递，服务端解码并校验有效期与签名
引入一次性 CSRF Token 防伪造
即使 Origin 正确、会话有效，攻击者仍可能诱导用户点击恶意链接，触发同域下的 WebSocket 连接。此时需要额外的“操作意图证明”。
- 服务端为每个用户会话生成唯一、时效性短（如 5 分钟）的 CSRF Token，并通过 HTTP 响应（如 Set-Cookie 或页面内 script 注入）送达前端
- 客户端建立 WebSocket 时，必须将该 Token 作为查询参数或自定义 header（如 X-CSRF-Token）携带
- 服务端在 onConnect 回调中比对 Token 是否匹配当前 session 存储的值，不一致则立即关闭连接（状态码 403）
配合前端安全机制形成纵深防御
后端防护必须与前端实践协同，否则容易被绕过。
- 页面渲染时，CSRF Token 应通过服务端模板注入（如 <meta name="csrf-token" content="...">），避免 JS 动态拼接导致 XSS 泄露
- 建立 WebSocket 前，检查 document.referrer 是否可信（辅助手段，不可单独依赖）
- 敏感操作（如发送指令、修改配置）不在 WebSocket 通道内直接执行，而是要求二次确认或携带操作签名
