[tecrodrigocastro]

Resumo

• Rate limiting nomeado (App\Providers\SecurityServiceProvider): login/password-reset (IP+e-mail), checkout/webhooks (IP), limites via .env (RATE_LIMIT_*)
• Headers de segurança globais: X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Content-Security-Policy (CSP mais frouxa só em /docs/*, que carrega Stoplight Elements do unpkg), Strict-Transport-Security quando HTTPS
• CORS restrito por CORS_ALLOWED_ORIGINS (não mais *), expõe X-Request-Id pro front conseguir ler via JS
• Arch test: nenhum controller usa $request->all()
• Logs em JSON estruturado (App\Logging\JsonFormatterTap) com request_id; App\Logging\RedactSensitiveDataProcessor redige password/token/api_key/secret/cartão automaticamente, em qualquer profundidade do context
• /up fora do grupo web (não depende de sessão/Redis pra responder), verificando banco e Redis de verdade — 503 com detalhe se algum cair, não 500 cru
• Sentry (sentry/sentry-laravel) instalado, desligado por padrão (SENTRY_LARAVEL_DSN vazio)
• docs/adr/0006-politica-de-segredos.md

Test plan

• composer check (pint + phpstan nível 8, com --memory-limit=512M — o SDK do Sentry precisa de mais memória — + rector --dry-run + pest, 48 testes) passa
• composer audit sem vulnerabilidades
• Teste confirma 429 depois de estourar o limite do limiter login
• Teste confirma os headers de segurança em toda resposta
• Teste confirma que log nunca contém senha (via RedactSensitiveDataProcessor, lendo o arquivo de log real)
• Testado via infra/dev.sh: /up responde 200 com banco/redis reais; /api/v1/ping com Origin libera CORS e expõe X-Request-Id