Autorização em nível de objeto
Endpoints que verificam quem está autenticado, mas não verificam se aquela pessoa pode acessar aquele registro específico.
Serviço 02 / 07 · Segurança ofensiva
Pentest de API
A sua API processa apenas as requisições que deveria processar?
Avaliação dos canais de integração entre sistemas, aplicações e parceiros, verificando se apenas requisições legítimas são processadas e o que acontece quando alguém pergunta algo que não deveria poder perguntar.
01 · O que é
O que este teste avalia
APIs são construídas para serem consumidas por máquinas, e é justamente por isso que costumam ser subestimadas. Sem uma interface visível, é fácil supor que um endpoint está protegido porque o aplicativo oficial não o chama daquele jeito. Na prática, qualquer pessoa pode chamá-lo do jeito que quiser.
O teste percorre cada endpoint com cada nível de privilégio disponível, verifica a arquitetura de integração e mede o que a camada de dados devolve em cada combinação. O objetivo é separar o que a API foi projetada para fazer daquilo que ela efetivamente permite.
Quando faz sentido
- 01
Ao publicar uma API nova ou abrir um canal de integração para parceiros e clientes.
- 02
Depois de alterar o modelo de autenticação, os escopos de token ou a estrutura de permissões.
- 03
Quando a mesma API atende públicos diferentes: aplicativo, parceiro externo e uso interno.
- 04
Quando a documentação e o comportamento real da API já não coincidem completamente.
02 · Riscos avaliados
O que costuma estar quebrado aqui
Nem todo achado aparece em todo ambiente. Estes são os padrões que a avaliação procura deliberadamente, porque são os que mais frequentemente sustentam um caminho completo até o impacto.
Autorização em nível de função
Operações administrativas acessíveis a perfis comuns, porque a restrição existe apenas na interface que esconde o botão.
Exposição excessiva de dados
Respostas que trazem mais campos do que o consumidor precisa, deixando a filtragem por conta do cliente que faz a chamada.
Consumo sem limites
Ausência de controle sobre volume, paginação e custo de operação, permitindo extração massiva ou degradação do serviço.
Fluxos de negócio encadeados
Sequências legítimas executadas fora de ordem para atingir um estado que o desenho não previu.
Superfície não documentada
Versões antigas, endpoints internos e rotas de depuração que continuam ativas e acessíveis.
03 · Superfície
Como enxergamos esse domínio
Antes de testar, mapeamos. O diagrama abaixo mostra a estrutura que orienta o trabalho e onde os pontos de verificação são posicionados.
- 01 Cliente aplicação, parceiro ou integração que consome a API
- 02 Gateway autenticação, limites de uso e roteamento: estar autenticado não é estar autorizado
- 03 Endpoints expostos /auth, /pagamentos, /clientes, /relatórios e /webhooks percorridos com cada nível de privilégio
- 04 Serviços e dados a resposta devolve mais do que o consumidor precisa
04 · O que testamos
Frentes de trabalho
A profundidade de cada frente depende do escopo acordado e da modalidade escolhida. Nada aqui é executado sem autorização formal.
Ver a metodologia completa- Matriz de autorização. Cada endpoint testado com cada papel, incluindo acesso cruzado entre contas.
- Autenticação e tokens. Emissão, expiração, escopo, revogação e reaproveitamento indevido.
- Modelagem de dados. Campos retornados, filtros aplicados no servidor e vazamento por relacionamento.
- Validação de entrada. Tipos, limites, formatos, injeção e desserialização de conteúdo.
- Fluxos críticos. Operações financeiras, aprovação, cancelamento e integrações com terceiros.
- Descoberta de superfície. Versões anteriores, rotas não documentadas e ambientes acessíveis.
05 · O que você recebe
A entrega ao final do trabalho
O relatório precisa servir a quem decide prioridade e a quem vai corrigir. Por isso a entrega é construída em camadas, e o ciclo só fecha com o reteste.
Solicitar avaliação- 01
Leitura executiva
O cenário de exposição traduzido para linguagem de negócio.
- 02
Relatório técnico
Cada achado descrito com o caminho percorrido e as condições para reproduzi-lo.
- 03
Evidências e provas de conceito
Demonstração concreta da exploração, sem depender de interpretação.
- 04
Priorização por impacto
As descobertas ordenadas pelo risco real para a sua operação.
- 05
Plano de correção
Recomendações práticas de remediação, orientadas ao seu contexto técnico.
- 06
Reteste das correções
Nova validação após a implementação, confirmando a eliminação do risco.
06 · Perguntas frequentes
Dúvidas comuns
Se a sua pergunta não estiver aqui, ela provavelmente é específica do seu ambiente. e é exatamente o tipo de coisa que a conversa inicial resolve.
Ajuda, mas não é obrigatória. Com especificação (OpenAPI, coleções, exemplos) o tempo é usado em profundidade em vez de descoberta. Sem ela, parte do trabalho é justamente mapear a superfície real, o que muitas vezes já revela endpoints que ninguém lembrava que existiam.
Sim. Uma API interna protege menos do que parece quando o atacante já obteve algum acesso à rede ou credenciais de um colaborador. Esse cenário pode ser incluído no escopo.
O teste de aplicação avalia o produto pela interface que os usuários enxergam. O teste de API avalia o canal diretamente, sem as restrições que a interface impõe, e é aí que costumam aparecer as falhas de autorização mais relevantes.
O escopo define quais operações de escrita são permitidas e em qual ambiente. Quando há gravação autorizada, os registros criados são identificáveis e informados no relatório.
07 · Superfícies relacionadas
Costuma fazer sentido junto com
Próximo passo
Quer avaliar a sua superfície de api?
A conversa inicial serve para entender o ambiente, o risco prioritário e o formato de teste adequado. Sem compromisso e sem exigir material técnico preparado.