Por que as APIs concentram o risco
Aplicações web e mobile são apenas a interface. Os dados, as regras de negócio e as integrações vivem na API. Por isso, quando algo vaza, o caminho quase sempre passa por um endpoint — muitas vezes por uma checagem de autorização ausente.
APIs também são mais difíceis de proteger do que interfaces gráficas. Não há cliques, telas ou fluxos visíveis: há contratos, tokens e permissões. Um endpoint esquecido, uma versão antiga ainda ativa ou um parâmetro a mais podem expor o que a interface escondia.
Somado a isso, APIs são feitas para serem consumidas por outros sistemas. Isso as torna alvo natural de automação: uma vez descoberta uma falha, ela é explorada em escala em minutos.
O OWASP API Top 10 em linguagem prática
O OWASP API Security Top 10 é a referência mais usada para priorizar riscos em APIs. Ele não é um checklist de ferramenta, e sim um mapa de onde as falhas costumam aparecer.
Na prática, três categorias concentram a maior parte do impacto: quebra de autorização (por objeto e por função), falhas de autenticação e exposição excessiva de dados. As demais — abuso de recursos, configuração e inventário — agravam esses problemas.
- Autorização quebrada por objeto (BOLA/IDOR).
- Autorização quebrada por função (BFLA).
- Autenticação e gestão de tokens frágeis.
- Consumo irrestrito de recursos (sem limite).
- Exposição excessiva de dados e erros verbosos.
- Inventário incompleto (APIs esquecidas/legadas).
BOLA e BFLA: as falhas que mais vazam dados
BOLA (Broken Object Level Authorization) acontece quando a API confia no identificador enviado pelo cliente e não verifica se aquele usuário pode acessar aquele objeto. Trocar um número de pedido, uma conta ou um documento passa a revelar dados de terceiros.
BFLA (Broken Function Level Authorization) é o equivalente no nível da função: um usuário comum consegue executar ações de administrador porque a permissão foi checada na tela, e não no servidor.
As duas falham silenciosamente: não geram erro, não aparecem em log e não disparam alertas. Por isso são tão comuns — e por isso precisam ser testadas de propósito, com dois usuários distintos.
Autenticação, sessão e tokens
Toda a segurança da API depende de saber quem está chamando. Falhas aqui anulam o resto: tokens sem expiração, segredos fracos, ausência de revogação, assinaturas mal validadas ou JWT com algoritmo confundível.
Testamos como os tokens são emitidos, armazenados e invalidados; se há limites de tentativa; e se a autenticação é consistente em todos os endpoints — inclusive nos internos e nos de administração.
- Expiração, renovação e revogação de tokens.
- Validação de assinatura e algoritmo (evitar JWT 'none').
- Proteção contra força bruta e reuso de credenciais.
- Consistência da autenticação em todos os endpoints.
Rate limiting e abuso de recursos
Sem limites, um único consumidor pode derrubar o serviço ou extrair dados em massa. APIs de busca, exportação e relatórios são os alvos preferidos para enumeração e scraping.
Além do limite por IP, avaliamos limites por conta, por token e por recurso, e se as operações caras são protegidas de forma proporcional ao custo que geram.
Exposição excessiva de dados
É comum a API devolver mais do que a tela precisa: campos internos, identificadores de outros usuários, mensagens de erro detalhadas ou metadados que ajudam um atacante a mapear o sistema.
Boas APIs devolvem o mínimo necessário. Avaliamos respostas de sucesso e de erro, filtros de campos e o comportamento de endpoints sob entradas inesperadas.
Como testamos uma API
O trabalho começa pelo mapeamento: descobrir os endpoints reais, incluindo os que não estão documentados. Depois, analisamos autenticação e autorização com perfis diferentes; em seguida, entradas, limites e erros.
Cada achado é documentado com evidência reproduzível: os passos exatos e o resultado observado, para que o time consiga validar e corrigir sem depender do avaliador.
Incluímos também testes de abuso: tentativas de enumeração, consumo repetido de recursos e manipulação de parâmetros, para medir como a API se comporta sob uso malicioso — não só sob uso correto.
- Reconhecimento e inventário de endpoints.
- Análise de autenticação e autorização (com 2+ perfis).
- Testes de entrada, parâmetros e regras de negócio.
- Verificação de limites, erros e exposição de dados.
- Relatório com evidências por endpoint e recomendação.
O que você recebe
O entregável é um relatório por endpoint, com severidade e recomendação prática. Ele serve ao time de API diretamente — não é uma lista genérica de boas práticas.
Conforme o escopo, o reteste confirma que as correções resolveram de fato, e não apenas que o sintoma desapareceu.
- Relatório com evidências por endpoint.
- Severidade e impacto de negócio por achado.
- Recomendações priorizadas por risco.
- Boas práticas de segurança para o time de API.
- Reteste das correções (conforme o escopo).
Erros comuns ao proteger APIs
A maioria dos incidentes não vem de tecnologia exótica, e sim de decisões previsíveis: proteger a tela e esquecer o servidor, confiar no cliente, deixar versões antigas ativas ou achar que autenticação resolve autorização.
Autenticação diz quem é você; autorização diz o que você pode fazer. Confundir as duas é a origem de boa parte das falhas de API.
- Checar permissão só no front-end.
- Confiar em identificadores enviados pelo cliente.
- Deixar endpoints legados ou de debug expostos.
- Não limitar consumo nem monitorar abuso.
- Devolver mensagens de erro detalhadas para o cliente.
Boas práticas contínuas
Segurança de API não é uma foto: é um processo. Documentar contratos, versionar, testar autorização a cada mudança e monitorar comportamento anômalo são medidas que reduzem risco de forma permanente.
Quando o time desenvolve com disciplina — contratos claros, testes e revisão — o teste de segurança passa a confirmar o que já está bem feito, em vez de descobrir o básico.
- Autorização testada no servidor, para cada objeto e função.
- Contratos documentados e versionados; desativar o que não é usado.
- Limites e cotas por conta e por token.
- Observabilidade: logs, métricas e alertas de abuso.
- Testes automatizados de autorização no CI/CD.
Autorização no servidor: o princípio que resolve a maioria
Se houver uma única regra para levar deste guia, é esta: a autorização acontece no servidor, a cada requisição, para cada objeto e cada função. Nada do que o cliente envia — identificadores, papéis, flags — pode ser tratado como verdade sem verificação.
Na prática, toda rota que lê ou escreve dados precisa responder a três perguntas antes de agir: quem está chamando, sobre qual recurso, e se essa combinação é permitida. Quando a resposta é 'a tela já escondia isso', o controle está no lugar errado.
Centralizar essa verificação reduz erro. Em vez de repetir a regra em cada endpoint, o time ganha um ponto único de decisão de acesso, testável e fácil de auditar. É mais fácil provar que uma regra está correta do que garantir que centenas de endpoints a repetem bem.
Vale lembrar que autenticação e autorização são camadas distintas e complementares. Autenticar bem não impede um usuário legítimo de acessar o que não deveria; só a checagem de autorização, feita sobre o recurso, faz isso. Separar mentalmente as duas evita achar que o problema está resolvido quando apenas o login está correto.
- Verifique posse/permissão no servidor, nunca no cliente.
- Trate identificadores e papéis recebidos como não confiáveis.
- Centralize a decisão de acesso e teste-a de forma automatizada.
- Aplique o mesmo rigor a leituras e a escritas.
Checklist rápido
Use esta lista para avaliar rapidamente a maturidade de segurança da sua API antes de um lançamento ou de uma contratação.
- Todo endpoint exige autenticação (salvo os públicos, de propósito)?
- Cada objeto é verificado contra o usuário autenticado?
- Funções administrativas são protegidas no servidor?
- Há limite de consumo por conta e por token?
- As respostas devolvem apenas o necessário?
- APIs antigas e de debug estão desativadas?
Perguntas frequentes
Testam APIs REST, GraphQL e gRPC?
Sim. Adaptamos as técnicas ao protocolo e ao estilo da API, cobrindo os riscos específicos de cada um, incluindo GraphQL.
Vocês testam com dados reais?
Priorizamos ambientes e dados de teste. Quando necessário, trabalhamos com dados mascarados, sempre dentro do escopo autorizado.
Preciso documentar a API antes?
Ajuda, mas não é obrigatório. Parte do trabalho é justamente descobrir endpoints que não estão na documentação.
Qual a diferença entre autenticação e autorização?
Autenticação confirma quem você é; autorização define o que você pode acessar. A maioria dos vazamentos vem de falhas de autorização.