PAV-34: Hardening de segurança (rate limit, CORS, headers)

[Jovinull]

Descrição

Hardening de segurança da PAV-34, sobre o que já existia na develop. Levantamento completo do estado atual no comentário do card. Este PR fecha as lacunas independentes:

1. Rate limit em POST /auth/register — os limiters já existiam mas eram aplicados só no POST /auth/login. Agora o cadastro usa authIpRateLimiter (por IP) + um novo authRegisterRateLimiter (por e-mail, bucket próprio, separado do de login) para conter criação de contas em massa e enumeração de e-mails.
2. HSTS — securityHeaders passa a enviar Strict-Transport-Security: max-age=31536000; includeSubDomains sobre HTTPS (req.secure, resolvido via trust proxy) ou NODE_ENV=production. preload fica de fora de propósito — entrar na lista de preload é decisão difícil de reverter e deve ser opt-in do time.
3. CORS fail-safe em produção — sem CORS_ALLOWED_ORIGINS, em production o fallback cai só nas origens *.candidate.app.br e loga um aviso; localhost nunca entra no allowlist de produção por fallback silencioso. Fora de produção o comportamento não muda.
4. Documentação — seção Segurança do BACKEND.md reescrita (rate limiting com limites/env vars/cobertura, CORS, cabeçalhos completos, limites de entrada) + AUTH_RATE_LIMIT_* adicionadas ao .env.example da raiz. Fecha a AC "configurações de segurança ficam documentadas".

Fora do escopo (com nota)

• Rate limit no endpoint de exportação (LGPD) — o endpoint não existe na develop, está na PAV-41 (feat(privacidade): exportar dados e excluir conta #240, em review). É follow-up de 2 linhas quando aquela mergear (ou vai no próprio PAV-41).
• CSP / stored-XSS / sanitização de output — é a PAV-132.
• Rate limiter global em todos os endpoints — o card pede "endpoints sensíveis", não compensa o risco de quebrar o dashboard.

Linear link

https://linear.app/candidateappbr/issue/PAV-34/hardening-de-seguranca-rate-limit-cors-headers-lgpd-basica

Como foi testado

Automatizado — npm run test --workspace=backend: 574/574 (+4 novos). Cobrem: HSTS presente com NODE_ENV=production e ausente sobre HTTP fora de produção; CORS em produção sem env bloqueia localhost e libera candidate.app.br; POST /auth/register retorna 429 com Retry-After após 5 tentativas para o mesmo e-mail.

Manual (stack local) — headers em GET /health: X-Content-Type-Options, X-Frame-Options: DENY, Referrer-Policy, Permissions-Policy presentes; HSTS ausente (dev/http, correto). POST /auth/register 6× para o mesmo e-mail: 201 → 409 × 4 → 429.

Checklist (LOCAL_DEVELOPMENT.md §14): instala do zero, app sobe, /health responde, testes do escopo passando, sem erro de TS no escopo, validado manualmente, sem regressão, logs limpos.

🤖 Generated with Claude Code

[Benevanio]

Status

⚠️ APROVADO COM RESSALVAS

Alerta

• 🟡 MÉDIO — backend/src/middleware/cors.ts:32 — Quando CORS_ALLOWED_ORIGINS não está configurado em produção, o fallback adotado está correto. Porém, o logWarn é executado a cada requisição cross-origin, podendo gerar volume contínuo de logs em ambientes com tráfego elevado. Isso aumenta ruído e custo de observabilidade e pode dificultar a identificação de alertas realmente relevantes.

Sugestão: registrar esse aviso apenas uma vez durante a inicialização da aplicação ou memorizar o estado de configuração ausente, evitando emitir o mesmo alerta repetidamente a cada requisição.

Não considero este ponto bloqueante para o merge, mas recomendo tratá-lo para evitar ruído desnecessário nos logs de produção.