Ferramentas de teste de segurança de API: as quatro categorias
Scanners
Procuram classes conhecidas de vulnerabilidade e configurações incorretas.
Boa abrangência, nenhuma compreensão das suas regras de negócio.
Proxies e interceptadores
Permitem que uma pessoa inspecione e manipule o tráfego.
Poderosos e totalmente dependentes de quem está conduzindo.
Fuzzers
Lançam entradas malformadas nos endpoints em busca de travamentos.
Encontram problemas de robustez, geram ruído que precisa de triagem.
A quarta é a verificação comportamental: a API recusa o que deveria recusar? Chamadas não autenticadas, acesso entre contas, limites de papéis, tokens expirados. Nenhum scanner consegue checar isso, porque depende do que o seu produto entende por permissão.
A lacuna que a maioria dos times tem
Em geral, os times têm um scanner no pipeline e um teste de invasão uma vez por ano. Os dois são úteis. Nenhum deles verifica se o endpoint que entrou no ar na terça-feira passada aplica autorização em nível de objeto, que é a falha mais explorada em APIs reais.
O motivo de isso ficar sem verificação é organizacional, não técnico. Parece uma questão de segurança, então fica esperando o processo de segurança, que roda a cada trimestre. Na prática é uma verificação de comportamento, que pertence à suíte de testes executada a cada mudança.
Como saber qual é a sua lacuna
Você consegue dizer quando foi a última vez que alguém verificou que o usuário A não consegue ler os dados do usuário B? Se a resposta for o teste de invasão anual, isso é uma janela de doze meses na sua falha mais provável.
Um endpoint novo ganha automaticamente uma verificação de permissão? Se depende de quem escreveu lembrar disso, vai passar batido.
Os achados do scanner passam por triagem ou só se acumulam? Um scanner que produz achados que ninguém lê é pior do que scanner nenhum, porque tem cara de cobertura.
Preenchendo a lacuna comportamental
Os planos de API gerados incluem categorias de autorização e de limites, então as verificações de permissão existem lado a lado com a cobertura funcional, e não como um exercício à parte. Isso as coloca na cadência de cada mudança, que é a única cadência capaz de acompanhar endpoints novos.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
A mesma configuração está disponível no painel do TestSprite, caso você prefira não instalar nada localmente. O restante da superfície do CLI está no repositório do CLI.
A mecânica está na documentação de testes de API.
Triagem, ou por que o scanner deixou de importar
Scanners falham de um jeito específico e comum: continuam funcionando e todo mundo para de ler o que eles produzem. Vale entender isso, porque não é um problema de ferramenta.
A primeira execução produz uma lista longa, boa parte dela não aplicável. Ninguém tem tempo de percorrer tudo, então a lista é lida por alto. A execução seguinte produz a mesma lista mais dois itens novos, invisíveis dentro do ruído que já existia. Em um trimestre, o relatório vira um artefato que é gerado e arquivado, e um achado de verdade pode ficar ali por um ano.
A correção é pouco glamourosa: faça a triagem da primeira lista uma vez, direito, e suprima o que não se aplica com uma justificativa escrita. Depois disso, o relatório mostra só o que mudou, e isso é uma coisa que as pessoas realmente leem. Um scanner sem triagem é pior do que nenhum, porque produz a aparência de cobertura.
O que rodar em cada lugar
Verificações de comportamento em cada pull request. Scanners em uma agenda fixa. Proxies e fuzzers nas mãos de alguém fazendo um trabalho focado. Um teste de invasão quando o modelo de ameaças muda, e não quando o calendário manda.
Se o pipeline pertence a outro time, o GitHub App é o caminho de menor resistência: é um webhook, não muda nada no seu repositório e dispara quando o seu build informa que a nova versão está no ar. Se você quiser a verificação visível dentro do repositório, um passo do GitHub Actions faz isso.
O que o TestSprite oferece na quarta categoria
Verificação comportamental: a API recusa o que deveria recusar? Os planos gerados incluem categorias de autorização e de limites, então cada endpoint é checado quanto a acesso não autenticado, leituras entre contas, limites de papéis e credenciais expiradas, a cada mudança.
Funciona contra o serviço em execução, pela interface dele, usando uma etapa de descoberta somada à sua especificação para saber o que existe. Auto-Authentication mantém as sessões vivas ao longo da execução, Dynamic Variables levam valores de uma chamada para outra, Dependency Chains derivam a ordem de execução do que cada caso precisa e produz, e Auto-Cleanup remove exatamente o que a execução criou.
O ganho é que a autorização em nível de objeto deixa de depender de alguém lembrar. Seu scanner continua cuidando das classes de dependência e de injeção, seu teste de invasão continua cuidando do abuso criativo, e a categoria que fica entre os dois deixa de ser tarefa de ninguém.
O TestSprite é uma ferramenta de teste de segurança de API?
Ele cobre a categoria comportamental: autorização, limites de papéis, valores-limite e higiene de erros. Não é um scanner e não procura classes de vulnerabilidade.
Ainda precisamos de um scanner?
Sim. Vulnerabilidades em dependências e classes de injeção são reais, e o scanner é o instrumento certo para elas. As categorias se complementam.
O que é autorização em nível de objeto?
É saber se um usuário consegue acessar o registro de outro usuário trocando um identificador. É a falha grave mais comum em APIs e uma das mais fáceis de testar.
Como evitar o ruído do scanner?
Faça a triagem em uma agenda fixa e suprima itens com uma justificativa anexada. Um backlog sem triagem é indistinguível de não ter scanner nenhum.
As verificações de comportamento podem rodar em produção?
Rodar em um ambiente representativo costuma ser a resposta certa. Criar e apagar registros em produção para testar permissões traz o seu próprio risco.
A categoria mais barata costuma ser justamente a que está faltando.
As ferramentas de teste de segurança de API se dividem em scanners, proxies, fuzzers e verificação comportamental. A maioria dos times tem a primeira e não tem a última, que é onde mora a autorização em nível de objeto. Coloque isso na cadência de cada mudança e mantenha o scanner em uma agenda fixa.