APIs: A Porta dos Fundos Que Ninguém Vigia

Seu frontend pode ser blindado. Seu login pode ter MFA. Mas se a API que retorna os dados do cliente aceita qualquer chamada sem validar permissões, tudo o que você construiu é teatro de segurança.

Os 5 Erros Mais Devastadores (Baseados no OWASP API Security Top 10)

#### 1. BOLA — Broken Object Level Authorization

O erro mais comum e mais perigoso. O usuário A consegue acessar dados do usuário B simplesmente trocando o ID na URL: /api/users/123 → /api/users/456.

Como testar: Intercepte a requisição com Burp Suite, troque IDs e observe se retorna dados de outro usuário.

#### 2. Autenticação Fraca em Endpoints Internos

APIs internas muitas vezes são "protegidas" apenas por estarem em uma rede privada. Com um SSRF (Server-Side Request Forgery), um atacante pode acessá-las de fora.

#### 3. Exposição Excessiva de Dados

A API retorna TODOS os campos do objeto (incluindo password_hash, internal_notes, credit_card_token) e confia no frontend para filtrar. Nunca confie no frontend.

#### 4. Rate Limiting Inexistente

Sem limitação, um atacante pode fazer brute force de credenciais, enumerar usuários ou exfiltrar todo o banco de dados com chamadas em massa.

#### 5. Injeção em Parâmetros

SQL Injection, NoSQL Injection e até GraphQL Injection continuam devastando APIs que não validam e sanitizam inputs.

Checklist de Hardening de APIs

• Autorização em CADA endpoint (não confie em middleware global sozinho)
• Rate limiting por IP e por token (3-5 req/s para endpoints sensíveis)
• Resposta mínima: retorne APENAS os campos necessários
• Input validation com schemas rígidos (Zod, Joi, JSON Schema)
• Logging de TODAS as tentativas de acesso não autorizado
• API Gateway com WAF (Web Application Firewall)

Na RET, cada API passa por testes automatizados de BOLA, fuzzing de parâmetros e análise SAST/DAST antes de ir para produção. Segurança de API não é feature — é pré-requisito.