Guia completo de observabilidade com OpenTelemetry: como instrumentar métricas, logs e traces e visualizar no Prometheus, Grafana e Jaeger
Se você já tomou um ataque de scraping que explodiu sua fatura de nuvem ou viu credenciais “vazando” por logs e tokens expirando no meio de uma jornada crítica do usuário, este guia é para você. Em 2026, proteger APIs REST vai muito além de firewall e “bearer token”. Aqui você vai aprender, de forma prática e aplicável, como fazer hardening de APIs com rate limiting no Nginx/Envoy, OAuth2/OIDC bem implementado, mTLS ponta a ponta e defesas reais contra o OWASP API Top 10 — sem soluções mágicas, só o que funciona no chão de fábrica.
Antes de falar de Nginx, Envoy ou chaves JWKs, alinhe a arquitetura. Segurança de API não é um componente: é o resultado de camadas complementares e de “guardrails” que se reforçam. Pense em três anéis concêntricos: perímetro (proxies, WAF e rate limit), identidade (OAuth2/OIDC, escopos, política de autorização) e transporte (mTLS, TLS moderno). No centro, a aplicação aplica autorização por objeto, valida entrada/saída e registra tudo de forma auditável.
O objetivo é simples: se uma camada falhar ou for burlada, outra detecta e mitiga. É como uma casa com tranca, alarme e câmeras. Não confie em apenas uma barreira. E, tão importante quanto construir, é observar e responder rapidamente: sem telemetria, todo o resto vira fé.
Rate limiting não é apenas “429 Too Many Requests”. É como organizar filas em uma bilheteria: você precisa priorizar clientes, evitar fura-filas e impedir que um grupo tome todos os guichês. Projetar chaves de limitação é metade da batalha: por IP, por API key, por ID do cliente (sub do JWT), por rota ou por método. Misture chaves para evitar que um atacante contorne limites só trocando IP ou token.
Use token bucket quando quiser picos controlados (ex.: 100 req/s com burst de 200). Leaky bucket suaviza rajadas e dá previsibilidade. Janela deslizante é ótima para análise mais justa ao longo de N segundos, reduzindo “picos artificiais” na virada da janela. O ponto prático: não há algoritmo perfeito; escolha o que melhor atende seu padrão de tráfego e monitore.
No Nginx, limites locais são simples e eficazes. Configure zonas com chaves que representem o “sujeito” real do consumo, como o claim sub do JWT, e aplique burst realista. Defina headers de feedback (ex.: X-RateLimit-Remaining) para melhorar a DX e evitar “tiro no pé” de clientes legítimos. Cuide do nodelay: ele pode aumentar a taxa efetiva em rajadas, então combine com limites rígidos por rota crítica.
Pontos de dor que vivi: limites por IP derrubam clientes por trás de NAT corporativo; aplicar o mesmo limite para todas as rotas penaliza health checks e endpoints idempotentes; e logar cada 429 sem amostragem pode gerar I/O storm. Nem todo 429 é malicioso; às vezes é um cliente mal configurado. Ofereça mensagens claras e documentação de cotas.
Para tráfego distribuído, o Envoy brilha com o rate limit filter e integrações a serviços remotos (por exemplo, via Redis) para limites globais coerentes entre instâncias. Use descriptors ricos: tenant + rota + método. Tenha políticas diferentes para tráfego interno e externo. E, principalmente, defina tempo de fallback: se o serviço de rate limit falhar, você prefere fail-open (risco de abuso) ou fail-closed (risco de indisponibilidade)? Em fintech e saúde, geralmente escolhemos fail-closed com allowlists para operações críticas.
Dica de ouro: diferencie 429 (limite atingido) de 503 (saturação). 429 indica regra aplicada; 503 sinaliza incapacidade temporária. Essa distinção acelera diagnósticos e evita “tuning” errado de clientes.
OAuth2/OIDC é a espinha dorsal da identidade da API. O erro mais comum não é “não usar”; é usar mal. Não aceite “qualquer JWT” só porque a assinatura bateu. Verifique aud (público), iss (emissor), exp/nbf, e se o token é de acesso e não um ID token. Faça cache de JWKs com expiração curta e suporte a rotação de chaves por kid.
Para usuários finais, prefira Authorization Code com PKCE. Para comunicação serviço a serviço, adote Client Credentials com escopos restritos e TTL curto. Evite tokens duradouros; uma janela de 5 a 15 minutos é um bom ponto de partida e ajuste conforme telemetria. Renove por refresh token em canais confiáveis, e revogue em eventos de risco.
Escopos amplos (ex.: “read:all”) são convenientes e perigosos. Prefira escopos específicos por domínio e complemente com políticas de autorização no backend, como ABAC (por atributos) e checagens por recurso. Quem pode ler a fatura 123 não é decidido só pelo endpoint, mas por uma verificação de posse do objeto. Essa é a cura prática para BOLA/BFLA.
Insight prático: registre o hash do JWT (jti ou at_hash) em logs de auditoria. Em incidentes, isso acelera correlação sem expor o token inteiro.
mTLS autentica cliente e servidor por certificado. Em APIs de parceiros e service-to-service, ele reduz ataque por credencial vazada e dificulta MITM. Pense nele como um “cracha” criptográfico. Porém, não confunda mTLS com autorização: ele diz quem é o chamador, não o que ele pode fazer. Combine com políticas de escopo e RBAC/ABAC.
Use CA interna e certificados de curta duração com renovação automatizada. Implemente rotação sem downtime e mantenha listas de revogação ativas. Em malhas de serviço, padrões como SPIFFE IDs e automação de emissão ajudam a manter sanidade. Garanta suporte a TLS 1.2+ e prioridade a 1.3, desabilitando cifras fracas.
Se você termina TLS no balanceador e fala em claro até o backend, perdeu o “ponta a ponta”. Quando precisar de inspeção L7, use recriptação e valide o certificado do lado upstream. Verifique SNI e políticas por host para evitar “bleed-over” entre domínios. E monitore erros de handshake: eles indicam expiração, cadeia mal formada e clocks desalinhados.
OWASP API Top 10 aponta padrões de falhas recorrentes. O segredo não é decorar a lista, mas transformar categorias em controles objetivos.
