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
Inventário, versionamento e superfície exposta
Uma das causas mais silenciosas de incidente em API é perder a conta de quais endpoints existem. Versões antigas que ficaram no ar, um endpoint de teste publicado sem querer, um host de homologação acessível pela internet: são as chamadas shadow APIs e zombie APIs, que ninguém monitora e quase sempre têm controles mais fracos. O OWASP API Security Top 10 trata isso como gestão inadequada de inventário justamente por ser tão frequente.
A defesa começa por saber o que está exposto. Manter um inventário vivo das APIs, com suas versões e ambientes, e usar a especificação (por exemplo OpenAPI) como fonte de verdade evita que endpoints escapem da governança. Ambientes de teste e produção precisam ficar separados, sem dados reais em teste, e versões descontinuadas devem ser efetivamente retiradas, não apenas marcadas como obsoletas.
- Manter inventário atualizado de APIs, versões e ambientes
- Retirar do ar versões descontinuadas em vez de só depreciar
- Separar ambientes de teste e produção, sem dados reais em teste
- Tratar a especificação como fonte de verdade e detectar desvios
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.
Camadas de defesa da API
Nenhum controle isolado sustenta a segurança de uma API. O desenho resiliente combina um gateway na frente, autenticação forte, autorização verificada dentro do serviço e validação estrita do que entra e do que sai. Cada camada assume que a anterior pode falhar, o que reduz o impacto de um erro pontual.
Validação de schema e atribuição de propriedades
Validar o corpo e os parâmetros contra um schema explícito, rejeitando campos desconhecidos, evita uma classe de problemas de uma vez. Aceitar cegamente o objeto enviado pelo cliente abre espaço para atribuição em massa, em que o usuário define um campo sensível que a interface nunca mostraria, como um indicador de papel administrativo. A regra é vincular apenas os campos esperados e verificar a autorização em nível de propriedade, não só de objeto.
Content-Type: application/json
X-Content-Type-Options: nosniff
Cache-Control: no-storeRequisições de servidor para servidor e SSRF
Quando a API busca uma URL informada pelo cliente, como um webhook ou uma imagem remota, ela pode ser induzida a acessar destinos internos, o que se chama server-side request forgery. A defesa é validar o destino contra uma lista de permissões, recusar endereços internos e o endpoint de metadados da nuvem, e resolver o nome antes de conectar para evitar contorno. Tratar a saída da API com o mesmo rigor da entrada fecha um vetor que passa despercebido.
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
- Manter inventário de APIs, versões e ambientes atualizado
- Retirar do ar versões descontinuadas e endpoints de teste
- Validar corpo e parâmetros contra schema, rejeitando campos desconhecidos
- Restringir as requisições de saída da API para conter SSRF
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
- Combine gateway, autenticação, autorização no serviço e validação de schema
- Verifique autorização em nível de propriedade, não apenas de objeto
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.
Versões antigas e endpoints de teste esquecidos no ar
Shadow APIs com controles fracos ampliam a superfície sem ninguém monitorar.
Aceitar o objeto do cliente sem validar o schema
Atribuição em massa deixa o usuário definir campos sensíveis não previstos.
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.
O que são shadow APIs e por que são perigosas?
Shadow APIs são endpoints que existem mas escapam da governança: versões antigas que ficaram no ar, hosts de teste expostos ou APIs publicadas sem passar pelo inventário. São perigosas porque costumam ter autenticação e validação mais fracas e ninguém as monitora. A defesa é manter um inventário vivo de APIs, versões e ambientes, retirar do ar o que foi descontinuado e usar a especificação como fonte de verdade.
O que é atribuição em massa e como evitar?
Atribuição em massa acontece quando a API vincula automaticamente os campos que o cliente envia ao objeto interno, permitindo que o usuário defina um campo que não deveria controlar, como um indicador de privilégio. A prevenção é validar o corpo contra um schema explícito, aceitar apenas os campos esperados e verificar a autorização em nível de propriedade, não só de objeto.
Como proteger uma API contra SSRF?
Quando a API acessa uma URL fornecida pelo cliente, valide o destino contra uma lista de permissões, recuse endereços internos e o endpoint de metadados da nuvem e resolva o nome antes de conectar para evitar contorno. Tratar as requisições de saída com o mesmo cuidado das de entrada fecha o server-side request forgery, um vetor que costuma passar despercebido.
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.