59 lines
2.2 KiB
Markdown
59 lines
2.2 KiB
Markdown
# 02. Rate Limiting & DDoS Protection
|
|
|
|
meta:
|
|
id: web-production-02
|
|
feature: web-production
|
|
priority: P1
|
|
depends_on: []
|
|
tags: [security, infrastructure, production]
|
|
|
|
objective:
|
|
- Implement robust rate limiting and DDoS protection beyond the basic in-memory tRPC middleware
|
|
|
|
deliverables:
|
|
- Redis-backed rate limiting for distributed deployment
|
|
- Per-endpoint rate limit tiers
|
|
- IP-based and user-based limiting
|
|
- DDoS protection via Cloudflare or similar
|
|
|
|
steps:
|
|
1. Replace in-memory rate limit map with Redis-backed solution:
|
|
- Use ioredis or @upstash/ratelimit for distributed rate limiting
|
|
- Create web/src/server/lib/ratelimit.ts with configurable tiers
|
|
2. Define rate limit tiers:
|
|
- Public endpoints (login, signup): 5 req/min per IP
|
|
- Authenticated API: 100 req/min per user
|
|
- Sensitive operations (password reset): 3 req/hour per email
|
|
- WebSocket connections: 1 per user, reconnect max 5/min
|
|
- Admin endpoints: 50 req/min per admin
|
|
3. Add IP-based rate limiting at edge/Nitro level for anonymous traffic
|
|
4. Configure Cloudflare (or alternative) for:
|
|
- DDoS protection
|
|
- Bot management
|
|
- Challenge pages for suspicious traffic
|
|
5. Add rate limit response headers (X-RateLimit-Remaining, X-RateLimit-Reset)
|
|
6. Implement sliding window algorithm for fairer limiting
|
|
|
|
tests:
|
|
- Unit: Test rate limiter correctly counts and resets
|
|
- Integration: Flood endpoint with requests, verify 429 responses
|
|
- Load: Use k6 or artillery to test limits under load
|
|
|
|
acceptance_criteria:
|
|
- Redis-backed rate limiting active on all endpoints
|
|
- 429 responses include Retry-After header
|
|
- Rate limits enforced per-IP, per-user, and per-endpoint
|
|
- DDoS protection layer active at edge
|
|
- No single IP can exceed 1000 req/min to any endpoint
|
|
- Rate limit headers present on all API responses
|
|
|
|
validation:
|
|
- `ab -n 1000 -c 10` against login endpoint → 429s after limit
|
|
- Verify Redis keys exist for rate limit counters
|
|
- Check Cloudflare dashboard for blocked threats
|
|
|
|
notes:
|
|
- Current in-memory rate limit in web/src/server/api/utils.ts will not work across multiple server instances
|
|
- Upstash Redis recommended for serverless deployments
|
|
- Consider implementing token bucket for burst tolerance
|