Mitgliederverwaltung/.plans/open/issue-214-no-rate-limiting-implementation.md

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:

   // 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:

   $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:

   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