WebSocket JWT validation bypasses centralized HTTP security controls
WebSocket JWT validation ran in its own code path, bypassing the centralized HTTP security middleware (rate limits, audit logging, claim normalization), creating drift between HTTP-authenticated and WebSocket-authenticated behavior.
Description
The HTTP layer enforced authentication, rate limiting, claim normalization, and audit logging through centralized middleware. The WebSocket layer revalidated JWTs through a separate code path that did not invoke the same middleware. As a result, security policies that applied to HTTP requests did not apply to WebSocket connections with the same token.
Impact
Drift between HTTP and WebSocket authentication policies: rate limits, blocklists, claim validation, and audit logs all behaved differently for the same token depending on transport. An attacker could prefer the WebSocket path to evade controls that would block them over HTTP.
Recommendation
Route WebSocket authentication through the same middleware stack as HTTP. If the WebSocket transport requires a different mechanism for token presentation, ensure all post-decode policies (rate limit, audit, claim validation) are shared code rather than parallel implementations.
Fair Casino: Fixed. Zealynx: Verified.