Artigo originalmente publicado em RET Tecnologia.
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.
Top comments (0)