As duas famílias de ferramentas de segurança de API
| Proteção, em tempo de execução | Gateways, firewalls de aplicação web, limitação de taxa, mitigação de bots, gerenciamento de segredos. Reduzem o que chega ao seu serviço. Comprados por times de plataforma ou de segurança. |
| Verificação, antes do lançamento | Scanners, fuzzers e verificações de comportamento sobre autorização e limites. Dizem o que o seu serviço faria. Comprados, ou não, pela engenharia. |
Onde confiar só na proteção falha
Um gateway não tem como saber que o usuário A não deveria conseguir ler o pedido do usuário B. Isso é uma regra de negócio, vive no seu código, e toda requisição que a exercita parece completamente legítima no tráfego. Método correto, token válido, caminho bem formado.
Autorização em nível de objeto é a falha mais explorada em APIs reais e é exatamente a classe que nenhuma camada de proteção enxerga. Ela precisa ser verificada dentro do serviço, antes do lançamento.
O que cada família cobre de fato
Gateways e firewalls: padrões de ataque conhecidos, requisições malformadas, volume. Valor real, e cegos para a lógica.
Limitação de taxa: abuso por volume. Não faz nada contra uma única requisição maliciosa bem formada.
Gerenciamento de segredos: vazamento de credenciais. Ortogonal a todo o resto daqui e vale a pena ter.
Scanners: vulnerabilidades em dependências, classes de injeção, configuração de TLS.
Verificação de comportamento: a API recusa o que deveria recusar. A mais barata, e a que mais falta.
Por que essa lacuna persiste
Verificar autorização pelo comportamento é barato, rende muito e falta em quase todo lugar, uma combinação estranha que vale explicar.
Ela cai entre dois donos. Parece trabalho de segurança, então a engenharia supõe que o processo de segurança cobre isso. O processo de segurança são scanners e uma avaliação anual, e nenhum dos dois conhece as suas regras de negócio, então ele supõe que os testes cobrem. As duas suposições são razoáveis isoladamente, e a lacuna sobrevive por anos.
Definir o dono já é a maior parte da solução. Quem escreve o endpoint escreve a verificação de autorização, no mesmo pull request, como parte normal do trabalho. Isso coloca a tarefa com a única pessoa que sabe quem deveria poder ver aquilo, e faz ela escalar com o número de endpoints, e não com o time de segurança.
A verificação que vale rodar esta semana
Crie duas contas. Use uma delas para criar um registro. Tente lê-lo com o token da outra. Se vierem dados, você tem a falha grave mais comum em APIs, e nenhum gateway na frente do seu serviço teria barrado isso.
Depois automatize, porque essa verificação precisa ser repetida a cada novo endpoint e ninguém vai lembrar.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Se você prefere não instalar nada, o dashboard faz a mesma coisa. Todo o resto que a linha de comando faz está no repositório do CLI.
Os planos de API gerados incluem categorias de autorização e de limites, então essas verificações ficam lado a lado com a cobertura funcional em vez de esperar por um exercício trimestral. O funcionamento está na documentação de testes de API.
Conecte o repositório pelo dashboard e as execuções partem do deploy que você já produz, ou então adicione um passo ao seu próprio workflow.
O que o TestSprite cobre na família de verificação
As verificações de comportamento que nenhuma camada de proteção consegue fazer: acesso sem autenticação, autorização em nível de objeto, limites de papéis, credenciais expiradas e entradas fora do intervalo válido. Os planos gerados incluem categorias de autorização e de limites, então todo endpoint as recebe, inclusive aquele que entrou na semana passada.
Ele atua sobre o serviço em execução pela interface dele, combinando descoberta e a sua especificação. O Auto-Authentication mantém as sessões vivas ao longo da execução, o Dynamic Variables leva valores de uma chamada para outra, o Dependency Chains deriva a ordem de execução e o Auto-Cleanup remove exatamente o que aquela execução criou.
O ganho é de cadência. Essas verificações não são difíceis, são fáceis de esquecer no quadragésimo endpoint, e rodá-las a cada mudança é o que fecha a lacuna mais explorada em APIs reais. Seu gateway e seu scanner seguem fazendo o que fazem bem.
O TestSprite é uma ferramenta de segurança de API?
Ele fica na família de verificação, cobrindo autorização, limites de papéis e valores de fronteira. Não é um gateway nem um scanner de vulnerabilidades.
Precisamos das duas famílias?
Sim. A proteção reduz o que chega até você; a verificação diz o que você faria com aquilo que passa. Nenhuma substitui a outra.
Um WAF consegue pegar autorização quebrada?
Não. A requisição é legítima em todos os aspectos que um WAF consegue inspecionar. Só o serviço sabe quem deveria ver aquele registro.
Por onde começar com um time pequeno?
Verificações de autorização por comportamento em todo endpoint que recebe um identificador. Maior taxa de acerto, menor custo, e rodam no pipeline que você já tem.
Com que frequência cada uma deve rodar?
A proteção fica sempre ligada. A verificação cabe a cada mudança, porque novos endpoints aparecem o tempo todo e cada um precisa da mesma verificação.
Um gateway não tem como conhecer as suas regras de negócio.
As ferramentas de segurança de API ou protegem uma API em execução ou verificam o que ela faria. A proteção é cega à lógica de autorização, que é onde mora a falha mais explorada. Faça o teste das duas contas e depois automatize.