WebSocket非法消息需在应用层校验：先解析JSON并检查字段合法性，再验证业务语义（类型白名单、权限、频次、签名等），最后按风险等级采取丢弃、警告、关闭连接或IP封禁等响应策略。
WebSocket 本身不提供内置的消息过滤或拦截机制，非法消息的识别与处理需在应用层实现——核心思路是：接收后校验，校验失败则丢弃、记录或主动关闭连接。
消息格式合法性检查
大多数非法消息源于格式错误，比如非 JSON 字符串、结构缺失字段、类型不符等。应在 onmessage 回调中第一时间解析并验证：
- 用
try...catch包裹JSON.parse()，捕获解析异常（如空字符串、乱码、截断数据） - 检查关键字段是否存在且类型正确（例如
data.type是字符串，data.payload符合预期结构） - 对字符串长度、嵌套深度、特殊字符（如控制字符、过长 key）做基础限制，防内存溢出或解析器崩溃
业务逻辑层面的非法判定
格式合法 ≠ 业务合法。需结合上下文判断消息是否应被接受：
- 校验消息类型是否在白名单内（如只允许
"chat"、"ping"，拒绝"delete_user"） - 验证用户权限（如普通用户发来的管理指令直接丢弃）
- 检查频率/频次（如 1 秒内收到 50 条相同操作，触发限流或标记为异常）
- 核对消息签名或时间戳（若协议约定带 HMAC 或有效期，过期或验签失败即视为非法）
拦截与响应策略
发现非法消息后，不能仅静默丢弃，需按风险等级采取明确动作：
立即学习“Java免费学习笔记（深入）”；
-
低风险（如字段缺失）：记录日志 + 发送警告帧（如
{type: "warning", code: "MISSING_FIELD"}），保持连接 -
中风险（如越权操作）：记录详细上下文（IP、用户 ID、原始消息）+ 关闭当前连接（
ws.close(4001, "Unauthorized action")） - 高风险（如疑似注入、协议扫描、大量畸形包）：关闭连接 + 临时封禁客户端 IP（服务端配合限流中间件）
服务端协同防御更可靠
前端拦截可被绕过，关键校验必须由服务端完成：
- WebSocket 服务端（如 Node.js 的
ws库、Java 的 Spring WebSocket）应复用同一套校验逻辑 - 避免在客户端生成敏感指令（如数据库操作），所有写操作必须经服务端鉴权和参数化处理
- 使用子协议（
Sec-WebSocket-Protocol）协商通信规范，服务端拒绝不匹配协议的连接
不复杂但容易忽略：很多项目只做前端 JSON 解析，却没对业务语义做约束，导致“合法 JSON”承载非法意图。真正的拦截，是格式校验 + 语义校验 + 行为监控三层叠加。
