#23714: Gateway: add websocket ingress limits for DoS hardening
gateway
size: M
trusted-contributor
Cluster:
Security Enhancements and Fixes
## 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
#23355: Gateway: fail closed on untrusted proxy headers
by bmendonca3 · 2026-02-22
81.2%
#23735: Gateway: add first-class wss validation and remote TLS guidance
by bmendonca3 · 2026-02-22
79.2%
#19515: security: add per-connection WebSocket rate limiting
by Mozzzaic · 2026-02-17
77.5%
#23420: Gateway: tighten WS connect schema bounds and validation
by bmendonca3 · 2026-02-22
75.5%
#13679: feat(gateway): make WebSocket maxPayload configurable
by andydoucet · 2026-02-10
74.7%
#19255: feat(gateway): add WebSocket connection metrics monitoring
by Wike-CHI · 2026-02-17
74.7%
#22766: fix(security): enable gateway auth rate limiting by default (CWE-307)
by brandonwise · 2026-02-21
74.5%
#20381: feat(gateway): make chat history byte limit configurable via `gatew...
by mgratch · 2026-02-18
74.0%
#23361: Gateway: reject scope assertions without identity binding
by bmendonca3 · 2026-02-22
74.0%
#6302: fix: Add timeouts to prevent indefinite hangs (issues #4954, #4956,...
by batumilove · 2026-02-01
73.8%