WebSocket DDoS: The Coverage Gap

Most WAF rate limit rules apply to HTTP requests -- which WebSocket connections are not, after the initial upgrade handshake. A WebSocket connection begins with a standard HTTP request (GET /ws HTTP/1.1 with Upgrade: websocket), which the WAF can inspect and rate limit. Once the connection is upgraded, traffic flows as WebSocket frames, which bypass HTTP-layer WAF inspection entirely. An attacker maintaining 10,000 concurrent WebSocket connections can send millions of messages per minute to the backend, none of which are counted by HTTP-based rate limit rules.

WebSocket DDoS is not theoretical. Real-time APIs (chat, trading, gaming, live dashboards) expose WebSocket endpoints that accept high-frequency messages by design. The connection model makes traditional defenses ineffective: you cannot rate limit based on request count when there are no requests after the initial upgrade, and you cannot close connections based on message content in the WAF layer because message framing is opaque to most WAF implementations.

Connection Exhaustion vs. Message Flood

WebSocket attacks take two forms. Connection exhaustion: an attacker opens the maximum number of WebSocket connections the server supports (limited by OS file descriptors and memory), holding each connection open while sending minimal traffic to prevent timeout. Each idle connection consumes memory -- typically 4-64KB depending on the application's per-connection buffer size. A server supporting 10,000 concurrent connections can be fully exhausted by a botnet maintaining those connections without sending any significant traffic.

Message flooding: an attacker maintains a smaller number of connections but sends messages at the maximum rate the server will accept. If the WebSocket handler triggers a database query or computation per message (as chat or trading endpoints typically do), the message rate directly maps to backend CPU and I/O load. A single WebSocket connection sending 1,000 messages per second can generate more backend load than 1,000 HTTP requests per second, depending on message processing cost.

WAF Coverage for WebSocket

WAF coverage for WebSocket is limited to the connection establishment phase. The HTTP upgrade request is inspectable: the WAF can rate limit the number of new WebSocket connections per IP, per time window, using standard HTTP rate limit rules applied to the upgrade endpoint path. Cloudflare's WAF applies rate limits to WebSocket upgrade requests using the same custom rule syntax as HTTP rate limits -- the key is to rate limit the upgrade path specifically, not just the general API path.

# Cloudflare: Rate limit WebSocket connection establishment
# Apply to the WebSocket upgrade endpoint
(http.request.uri.path eq "/ws" and http.request.headers["upgrade"] eq "websocket")
# Action: Rate limit
# Characteristics: [ip.src]
# Period: 60 seconds
# Requests per period: 5 (5 new WebSocket connections per minute per IP)
# This limits connection exhaustion attacks without affecting established connections

Application-Layer Controls

Post-upgrade message rate limiting and per-connection message limits must be implemented in the application code or WebSocket server configuration, not the WAF. Most production WebSocket server libraries provide hooks for implementing per-connection rate limits: a message queue per connection with a maximum depth, a per-connection messages-per-second counter, and a connection close trigger when either limit is exceeded. Redis-backed rate limiters can track message rates across a distributed WebSocket server cluster.