← Back to PRs

#23714: Gateway: add websocket ingress limits for DoS hardening

by bmendonca3 open 2026-02-22 16:25 View on GitHub →
gateway size: M trusted-contributor
## Summary - add WS ingress connection guards in `attachGatewayWsConnectionHandler`: - per-IP concurrent connection cap - per-IP pre-auth connect attempt rate limit (sliding window) - add WS request backpressure guard in the message handler to reject/close when queued in-flight requests exceed a per-connection cap - wire server max payload through a runtime getter (test-overridable) so frame-size enforcement can be validated in CI - advertise the effective max payload in `hello-ok` policy payload - add dedicated e2e coverage for all new limits ## Tests - `pnpm test:e2e src/gateway/server.ws-limits.e2e.test.ts` - `pnpm test:e2e src/gateway/server.auth.e2e.test.ts` - `pnpm check` <!-- greptile_comment --> <h3>Greptile Summary</h3> Added DoS hardening for WebSocket gateway connections with three layered protections: per-IP concurrent connection limits (24 default), pre-auth connection rate limiting (40 attempts/10s window), and per-connection in-flight request backpressure (64 queued messages). Max payload enforcement now uses runtime getters for test overrides, and the effective limit is advertised in `hello-ok` policy. - Per-IP connection tracking prevents single-IP connection exhaustion - Sliding window rate limiter prevents rapid connection cycling attacks - Request queue backpressure prevents slowloris-style attacks that keep connections open while queuing many requests - All limits are test-overridable via environment variables and covered by e2e tests - `connectAttemptsByIp` map has no cleanup mechanism, will grow unbounded over time (memory leak) <h3>Confidence Score: 3/5</h3> - Safe to merge with one memory leak that should be addressed before production - The DoS hardening implementation is well-structured with comprehensive test coverage and appropriate limit values. However, the `connectAttemptsByIp` map lacks cleanup for expired rate limit windows, which will cause unbounded memory growth in long-running gateway processes under sustained connection attempts. The implementation correctly handles connection tracking cleanup and provides good defense-in-depth with three layers of protection. - Pay close attention to `src/gateway/server/ws-connection.ts` - the rate limiter map needs cleanup logic added <sub>Last reviewed commit: d87614a</sub> <!-- greptile_other_comments_section --> <!-- /greptile_comment -->

Most Similar PRs