Files
Mitgliederverwaltung/.plans/open/issue-214-no-rate-limiting-implementation.md
T
shahondin1624 b29a268b1d Restructure .plans/ into done/ and open/ subdirectories
- Move completed plan files to .plans/done/
- Move 18 open plan files to .plans/open/
- Update .gitignore to exclude .verified_plans temp file
- Verified all 18 open plans still describe unimplemented issues
2026-04-28 20:30:55 +02:00

55 lines
1.6 KiB
Markdown

# Issue #214: Rate Limiting Not Fully Implemented
## Problem
The `RateLimitMiddleware` exists but may not be properly configured or may have gaps:
1. **Bulk operations not rate-limited**: The `revealAllergies()` endpoint iterates over ALL members and decrypts each — this should be rate-limited per admin session.
2. **No per-endpoint limits**: Search endpoints could be abused for enumeration attacks.
3. **No limit feedback**: When rate limited, users don't know when they can retry.
## Impact
- Potential DoS via expensive operations (bulk decryption)
- Enumeration attacks on search endpoints
- Poor UX with no retry-after information
## Solution
1. Add specific rate limits to expensive endpoints:
```php
// In middleware configuration
'member.allergien.reveal' => ['limit' => 1, 'period' => 3600], // 1 per hour
'member.search' => ['limit' => 30, 'period' => 60], // 30 per minute
```
2. Return proper rate limit headers:
```php
$response->headers->set('X-RateLimit-Remaining', (string)$remaining);
$response->headers->set('X-RateLimit-Reset', (string)$resetTime);
```
3. Return 429 with Retry-After header when limited:
```php
return new JSONResponse(['error' => 'Rate limit exceeded'], 429, [
'Retry-After' => $secondsRemaining
]);
```
## Tasks
- [ ] Audit all endpoints for rate limit requirements
- [ ] Configure per-endpoint rate limits
- [ ] Add X-RateLimit-* response headers
- [ ] Return 429 with Retry-After when limited
- [ ] Document rate limit configuration
- [ ] Add tests for rate limiting behavior
## Labels
- enhancement
- security
- backend
- priority:medium