Checklist de Testes de Segurança de API: Quem Verifica o Quê

O checklist de testes de segurança de API, agrupado por quem verifica cada item

Coberto pela verificação funcional automatizada

São verificações comportamentais: a API responde corretamente a uma requisição que deveria recusar? Elas pertencem à sua suíte regular e devem rodar a cada mudança.

• Acesso não autenticado é recusado. Todo endpoint protegido, chamado sem credenciais, retorna a rejeição correta em vez de dados.

• A autorização é aplicada por objeto. O usuário A não consegue ler nem modificar os registros do usuário B trocando um identificador no path. Essa é a falha mais explorada em APIs reais e é uma verificação comportamental simples.

• Os limites de papéis se sustentam. Um papel somente leitura não consegue escrever. Um token expirado ou revogado é rejeitado.

• A validação de entrada rejeita valores fora do intervalo. Casos de fronteira em todos os parâmetros, inclusive naqueles que ninguém documenta.

• Os erros não vazam detalhes internos. Stack traces, fragmentos de query e hostnames internos ficam fora das respostas.

Precisa de um scanner ou de uma ferramenta especializada

• Vulnerabilidades em dependências e bibliotecas.

• Classes de injeção: SQL, comandos, templates, desserialização.

• Configuração de TLS e tratamento de certificados.

• Sondagem de CVEs conhecidos na sua stack.

Precisa de uma pessoa

• Abuso de lógica de negócio. Pedir uma quantidade negativa, repetir um desconto, pular uma etapa de um fluxo que pressupunha ordem.

• Modelagem de ameaças e a decisão sobre o que são, de fato, os dados sensíveis.

• Qualquer coisa que exija criatividade sobre como alguém usaria seu produto de forma indevida.

O item que as pessoas pulam

A autorização em nível de objeto é o item que mais costuma faltar e o mais fácil de verificar. Crie duas contas, faça uma delas criar um registro e tente lê-lo com o token da outra. Se isso retornar dados, você tem a falha grave de API mais comum do setor, e basta um teste para encontrá-la.

Automatizar isso compensa todo o esforço, porque a verificação precisa ser repetida para cada novo endpoint e nenhuma pessoa vai lembrar de fazer isso.

Colocando a metade automatizável para rodar de verdade

Os planos de API gerados incluem categorias de autorização e de fronteira, então essas verificações existem junto com sua cobertura funcional, em vez de virarem um exercício de segurança separado que ninguém agenda.

O dashboard cobre o mesmo terreno para quem não quer uma instalação local, e toda a superfície de comandos está no repositório da CLI.

A mecânica está na documentação de testes de API.

As duas contas que você deveria manter permanentemente

Quase todo item comportamental desta lista precisa de dois usuários, e a coisa mais barata que você pode fazer é manter um par de contas de teste em cada ambiente, em vez de criá-las a cada teste.

Faça com que elas sejam diferentes nos aspectos que importam para o seu produto: donos diferentes, papéis diferentes se você tiver papéis, idealmente organizações diferentes. Aí cada verificação de autorização vira um teste de duas linhas em vez de um exercício de preparação, e as pessoas realmente passam a escrevê-las.

A versão que dá errado é criar contas dentro de cada teste. É mais lento, deixa dados para trás e faz a verificação depender do seu fluxo de cadastro estar funcionando, então um cadastro quebrado deixa todo teste de permissão vermelho pelo motivo errado. Contas permanentes, criadas uma única vez, eliminam tudo isso.

Cadência por grupo

Verificações comportamentais a cada mudança. Scanners de forma agendada e no release. Revisão humana quando o modelo de ameaças muda, ou seja, quando você adiciona um novo tipo de dado ou um novo tipo de usuário.

Conecte o repositório pelo dashboard e as execuções partem do deployment que você já produz, ou, em vez disso, adicione um passo ao seu próprio workflow.

Como o TestSprite cobre o terço automatizável

Os planos de API gerados incluem categorias de autorização e de fronteira, então os itens comportamentais desta lista existem junto com sua cobertura funcional, em vez de virarem um exercício separado que alguém precisa agendar.

Isso significa que acesso não autenticado, autorização em nível de objeto, limites de papéis, tokens expirados e entradas fora do intervalo são verificados a cada mudança, contra o serviço em execução, para cada endpoint, inclusive os que foram adicionados na semana passada. Auto-Authentication mantém as sessões vivas durante toda a execução, Dynamic Variables levam valores de uma chamada para outra, Dependency Chains derivam a ordem de execução a partir do que cada caso precisa e produz, e Auto-Cleanup remove exatamente o que a execução criou.

O valor está na cadência, não na esperteza. Essas verificações não são difíceis de escrever; são difíceis de lembrar no quadragésimo endpoint. Tê-las geradas e executadas continuamente é o que fecha a brecha mais explorada em APIs reais sem criar um processo que alguém precise seguir.