Pentest em APIs: pontos críticos de autenticação, autorização e exposição
APIs concentram lógica e dados e falham mais em autorização do que em injeção. Veja onde o risco realmente está.
APIs são a espinha dorsal das aplicações modernas e, por isso, um alvo de altíssimo valor. Diferente do que muita gente imagina, os problemas mais comuns em APIs não são injeções clássicas, e sim falhas de autorização: um usuário acessando dados de outro, ou executando uma função que não deveria. O OWASP API Security Top 10 reflete bem isso, com a quebra de autorização em nível de objeto e de função no topo da lista.
Este guia trata, de forma defensiva, dos pontos que um pentest de API examina e que sua equipe deve fortalecer. O foco é entender onde o risco se concentra e como reduzir, sem instruções de exploração.
Autenticação e tokens
A autenticação de APIs frequentemente usa tokens como JWT ou fluxos OAuth. Os problemas surgem nos detalhes: validação fraca de assinatura, expiração longa demais, ausência de revogação e segredos mal protegidos. Um JWT bem decodificado mostra claims, emissor e expiração, mas decodificar não é validar; a API precisa verificar assinatura, emissor, audiência e validade a cada requisição.
Tokens de longa duração sem mecanismo de revogação são perigosos: se vazam, valem por muito tempo. Prefira expiração curta com renovação controlada e tenha um caminho para revogar credenciais comprometidas.
Autorização: BOLA e BFLA
A falha mais comum e mais cara em APIs é a quebra de autorização em nível de objeto, conhecida como BOLA: a API autentica o usuário, mas não verifica se aquele usuário tem direito ao objeto solicitado. Trocar um identificador na requisição passa a retornar dados de outra pessoa. A correção é validar a propriedade do recurso no servidor, em toda requisição, nunca confiando no identificador enviado pelo cliente.
A quebra de autorização em nível de função, ou BFLA, é parecida, mas envolve ações administrativas ou privilegiadas expostas a quem não deveria. Endpoints sensíveis precisam verificar o papel do chamador no servidor, e não depender de a interface simplesmente não mostrar o botão.
- Validar propriedade do objeto no servidor, em toda requisição
- Verificar papel e permissão para funções sensíveis no backend
- Não confiar em identificadores ou flags enviados pelo cliente
- Aplicar o mesmo controle de acesso a todos os métodos e versões
Exposição, validação e abuso
APIs tendem a expor mais dados do que a interface usa, deixando o filtro para o cliente. Isso vaza informação sensível para quem inspeciona o tráfego. Retorne apenas os campos necessários para cada contexto. Valide a entrada de forma estrita no servidor e trate erros sem revelar detalhes internos que ajudem um atacante.
Sem rate limiting, APIs ficam sujeitas a abuso, força bruta e raspagem em massa. Limite por identidade e por origem, e monitore padrões anômalos. Logs de API são essenciais tanto para detecção quanto para investigação.
Checklist prático
- Validar assinatura, emissor, audiência e expiração dos tokens no servidor
- Usar expiração curta com renovação e caminho de revogação
- Validar propriedade de objeto em toda requisição (evitar BOLA)
- Verificar papel e permissão para funções sensíveis (evitar BFLA)
- Não confiar em identificadores ou flags do cliente
- Retornar apenas os campos necessários, sem exposição excessiva
- Validar entrada de forma estrita no servidor
- Aplicar rate limiting por identidade e origem
- Tratar erros sem vazar detalhes internos
- Registrar logs de API para detecção e investigação
Boas práticas
- Centralize a autorização no backend e aplique de forma consistente
- Trate cada endpoint e versão com o mesmo rigor de acesso
- Minimize os dados retornados ao estritamente necessário
- Use expiração curta e revogação para limitar tokens vazados
- Monitore abuso com rate limiting e detecção de anomalia
- Versione e documente a API para reduzir endpoints esquecidos
Erros comuns
Confiar no identificador enviado pelo cliente
Quebra de autorização em nível de objeto (BOLA) e vazamento de dados de outros usuários.
Funções sensíveis sem checagem de papel no servidor
Usuários comuns executam ações administrativas (BFLA).
Tokens de longa duração sem revogação
Um token vazado permanece válido por muito tempo.
Resposta retornando mais dados que o necessário
Exposição de informação sensível para quem inspeciona o tráfego.
Ausência de rate limiting
Abuso, força bruta e raspagem em massa sem barreira.
Quando procurar apoio especializado
APIs exigem um olhar específico sobre autorização e exposição de dados. A GUARDIASEC avalia APIs REST e GraphQL no serviço de Pentest, validando autenticação, autorização e exposição com evidência e priorização por risco.
Perguntas frequentes
O que é BOLA e por que é tão comum em APIs?
BOLA é a quebra de autorização em nível de objeto: a API autentica o usuário, mas não verifica se ele tem direito ao objeto solicitado. É comum porque a autenticação costuma estar presente e dá uma falsa sensação de segurança, enquanto a verificação de propriedade do recurso fica esquecida. A correção é validar a propriedade no servidor em toda requisição.
Decodificar um JWT é o mesmo que validar?
Não. Decodificar apenas revela o conteúdo do token, que é legível por qualquer um. Validar exige verificar a assinatura com a chave correta e conferir emissor, audiência e expiração. Conteúdo legível não prova autenticidade, então a API precisa validar o token a cada requisição, e não apenas lê-lo.
GraphQL muda a forma de testar a API?
Sim em parte. GraphQL concentra tudo em um endpoint e permite consultas flexíveis, o que traz preocupações próprias, como consultas muito profundas, exposição excessiva de campos e autorização por campo. Os princípios de autorização no servidor e minimização de dados continuam valendo, mas a superfície e os controles têm particularidades.
Rate limiting é suficiente para proteger uma API?
Não sozinho. Rate limiting mitiga abuso, força bruta e raspagem, mas não corrige falhas de autorização ou exposição de dados. Ele é uma camada importante que precisa ser combinada com autenticação robusta, autorização no servidor, validação de entrada e minimização do que a API retorna.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.