WebSocket Security: The Attack Surface Most API Teams Skip

WebSockets upgrade from HTTP but then operate completely differently. A standard HTTP API request is authenticated per-request, rate limited per-request, and validated per-request. A WebSocket connection authenticates once at upgrade time and then maintains a persistent bidirectional channel. Everything sent over that channel after the handshake bypasses per-request controls.

The Specific Risks

Authentication drift

Authentication happens at WebSocket upgrade, not per-message. If a user's permissions change after the connection is established — they're downgraded, suspended, or their token is revoked — the existing connection remains authenticated. A connection opened at 9am with valid credentials is still open at 5pm with the same permissions even if the user was deprovisioned at noon.

IP bypass via X-Forwarded-For

WebSocket connections often go through different network paths than HTTP requests. If your IP-based rate limiting and geo-blocking relies on X-Forwarded-For headers, an attacker connecting directly to your origin server can forge these headers — bypassing controls that would catch them on the HTTP layer.

Message flooding

A single authenticated WebSocket connection can send thousands of messages per second. If you don't enforce per-connection message rate limits, a single compromised session can saturate your message processing capacity.

The Right Controls

• ▸Re-authenticate connections periodically — validate the session token on a timer, not just at upgrade
• ▸Enforce per-connection message rate limits independently of per-request HTTP limits
• ▸Use CF-Connecting-IP (or equivalent) rather than X-Forwarded-For for client IP identification
• ▸Apply message schema validation on every incoming frame, not just at connection establishment
• ▸Set connection timeouts — indefinitely persistent connections are rarely legitimate