DevByte-Community / DevByte-Community/Community-API-Backend
Implement Rate Limiting for Critical Endpoints
- Linguagem predominante
- JavaScript
- Estrelas
- 2
- Forks
- 11
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Descrição
Ticket ID: SEC-RATELIMIT-001
Priority: High
Security Level: CRITICAL
**Feature Description**
Implement rate limiting on critical API endpoints to prevent abuse, brute force attacks, and ensure fair usage of platform resources. Protect authentication, registration, and data-intensive endpoints.
**Acceptance Criteria**
1. Protected Endpoints ✅
- High Priority (Strict Limits):
- POST /api/auth/login - 5 attempts per 15 minutes per IP
- POST /api/auth/register - 3 attempts per hour per IP
- POST /api/auth/forgot-password - 3 attempts per hour per IP
- POST /api/auth/reset-password - 5 attempts per hour per IP
- Medium Priority (Standard Limits):
- GET /api/metrics/dashboard - 30 requests per minute per user
- POST /api/projects - 10 creations per 30 minutes per user
- POST /api/events - 10 creations per 30 minutes per user
- POST /api/blogs - 5 creations per 30 minutes per user
- General Protection:
- All other authenticated endpoints: 100 requests per minute per user
- All public endpoints: 60 requests per minute per IP
2. Implementation Requirements ✅
- Use express-rate-limit middleware or another
- Redis store for distributed rate limiting (production)
- Memory store for testing
- Clear, consistent HTTP headers:
```
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 95
X-RateLimit-Reset: 1633039200
Retry-After: 60 (when blocked)
```
3. Response Format ✅
```
json
{
"error": "Too Many Requests",
"message": "Rate limit exceeded. Please try again in 60 seconds.",
"retryAfter": 60,
"timestamp": "2024-01-15T10:30:00Z"
}
```
`Status Code: 429 Too Many Requests`
4. Configuration ✅
Environment-based configuration:
```
env
RATE_LIMIT_ENABLED=true
RATE_LIMIT_WINDOW_MS=60000
RATE_LIMIT_MAX_REQUESTS=100
```
- Different limits for development/production
- Ability to disable for specific routes (webhooks, health checks)
5. Skip List ✅
- Exclude from rate limiting:
- GET /api/health - Health checks
- GET /api/docs - API documentation
- Internal webhook endpoints (specify which)
6. Monitoring & Logging ✅
- Log rate limit hits with context (user, endpoint, IP)
- Send alert on sustained rate limit violations (>10 blocks in 5min)
- Metrics exposed: rate_limit_hits_total, rate_limit_blocks_total
- Admin endpoint to view current rate limit status: GET /api/admin/rate-limits/status
8. Documentation ✅
- Create a security docs folder and draft a detailed rate_limit.md file explaining the overall strategy
9. Testing ✅
- Unit tests for rate limit middleware
- Integration tests verifying limits work correctly
Guia de contribuição
Direção de pesquisa
Nenhum arquivo do repositório ou caminho de teste foi indicado. Comece localizando as rotas de API existentes e os pontos de entrada do middleware para os endpoints de autenticação, registro, senha, métricas, projeto, evento, blog, saúde, documentação, webhook e administração; em seguida, revise os testes unitários e de integração necessários. O trabalho estará concluído quando os limites listados, os headers, a resposta 429, a configuração, as exclusões, o monitoramento, o store de produção do Redis, o store de teste em memória e a documentação de segurança estiverem cobertos.
Escrita pelo modelo de indexação a partir do texto da issue.
Avaliação
- Stack de tecnologia
- express, javascript, redis
- Domínio
- api, backend, documentation, observability, security, testing
- Tipo de issue
- Funcionalidade
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Status de atividade
- Estagnada
- Clareza
- Precisa de esclarecimento
- Facilidade para iniciantes
- 25/100