Uma transferência de R$ 8 mil deveria ser recusada porque o limite permitido é de R$ 1 mil. Depois de uma atualização, a API passa a aceitá-la. O serviço continua no ar, a requisição segue o formato esperado e a resposta diz que a operação foi concluída.
Nesse exemplo hipotético, a falha está no valor que a aplicação deixou movimentar. Quem olha só a disponibilidade do serviço ou a estrutura da resposta não vê o problema.
É por isso que a validação de APIs após mudanças precisa checar as regras que cada operação deve respeitar. Permissões, limites, sequência de etapas e tratamento de falhas fazem parte desse trabalho, mesmo quando o contrato da API continua igual.
Para quem lidera Engenharia, Arquitetura ou Segurança, o desafio é manter essa avaliação no ritmo das entregas sem perder de vista o impacto de uma falha no negócio.
Como uma mudança pode introduzir riscos em APIs
O comportamento de uma API depende do código que executa a operação, dos serviços consultados, das configurações e dos controles aplicados ao longo do fluxo. Uma alteração em qualquer desses pontos pode mudar o resultado.
Considere uma atualização no componente que verifica limites de transferência. O endpoint continua recebendo os mesmos campos e devolvendo a mesma estrutura de resposta. Ainda assim, se a verificação deixar de valer em uma das condições previstas, a operação passa a ser aprovada indevidamente.
Algo parecido acontece ao revisar permissões, trocar um fornecedor ou alterar o tratamento de uma resposta de erro. A mudança parece restrita a uma parte do sistema, mas os efeitos alcançam quem depende dela.
A especificação mostra alterações em endpoints e contratos. Mudanças internas e em dependências também alteram o comportamento, e essas não aparecem no documento.
O que são falhas de lógica de negócio em APIs
Falhas de lógica de negócio ocorrem quando a aplicação permite uma operação que contraria as regras do processo que deveria executar. Uma entrada pode ter o formato correto, usar uma credencial válida e, mesmo assim, produzir um resultado indevido.
Na transferência, o valor informado é um número válido. O problema aparece quando ele é comparado ao limite permitido para aquela operação.
Outras regras dependem do estado do processo. Um pedido só pode ser despachado depois da confirmação do pagamento. Um reembolso precisa considerar o que já foi devolvido. Uma aprovação pode exigir etapas que não devem ser puladas.
O guia de testes da OWASP inclui a avaliação de fluxos que permitem pular, repetir ou executar etapas fora da ordem prevista. Os casos de teste partem dos requisitos específicos de cada aplicação. OWASP Web Security Testing Guide.
Quais comportamentos precisam ser reavaliados
Os exemplos abaixo são hipotéticos. Cada um mostra uma situação que merece investigação, dependendo do que mudou.
Acesso com outro perfil
Uma revisão de permissões permite que um usuário autenticado consulte informações de outra conta. A avaliação precisa verificar se a resposta traz só os dados que aquele usuário deveria ver.
Repetição de uma operação
Uma integração reenvia uma solicitação depois de não receber a confirmação a tempo. Se a operação deveria produzir um único efeito, a avaliação precisa verificar se a repetição gerou uma cobrança, reserva ou baixa a mais.
Falha em uma dependência
Um serviço externo para de responder durante o processamento. Aqui é preciso verificar o estado final da operação e se a API informou um resultado compatível com o que de fato aconteceu.
Uso acima do previsto
Uma funcionalidade aceita solicitações que, uma a uma, são permitidas, mas cujo uso repetido prejudica o negócio. Esse tipo de preocupação aparece no API6:2023 da OWASP, que trata do acesso irrestrito a fluxos de negócio sensíveis, como compras e reservas. OWASP API Security Top 10.
Esses casos exigem critérios de aceitação claros. A equipe precisa saber qual resultado é permitido, em quais condições e o que deve acontecer quando a operação não puder ser concluída.
Por onde começar quando não é possível reavaliar tudo
Uma forma prática de priorizar a validação de APIs é cruzar o que mudou com as consequências de um comportamento indevido.
Uma alteração numa consulta informativa e uma mudança na autorização de pagamentos não pedem o mesmo esforço. Também importa saber quantos sistemas dependem do componente alterado e quais condições a cobertura atual já verifica.
Para selecionar o escopo, vale responder:
- Quais operações dependem do código, da configuração ou da integração que mudou?
- Quais regras precisam continuar válidas nessas operações?
- O que acontece se uma dessas regras deixar de ser aplicada?
- Os testes existentes verificam esse comportamento, inclusive diante de recusas, repetições e falhas?
As respostas mostram onde a avaliação precisa ir mais fundo. Um componente compartilhado por vários serviços, por exemplo, pode exigir uma análise mais ampla do que o endpoint alterado sugere.
O papel da validação contínua de APIs
Validação contínua de APIs é a prática de reavaliar o comportamento delas a cada versão do sistema, revisando a cobertura conforme surgem mudanças e novos riscos.
Uma suíte de regressão cobre parte importante desse trabalho. Mas ela precisa acompanhar os requisitos atuais: um teste criado para a integração antiga não verifica uma condição que só o novo fornecedor introduziu.
Na prática, a rotina de validação tem duas frentes: manter as verificações relevantes e investigar o que ainda não está coberto. A frequência e a profundidade dessas avaliações dependem da criticidade das APIs e do que mudou.
Há também uma tarefa de alinhamento. Produto e negócio ajudam a explicitar os limites da operação; Engenharia, QA e Segurança transformam essas regras em comportamentos verificáveis. Quando o resultado esperado fica implícito, fica mais difícil demonstrar que ele continua sendo respeitado.
Como verificar se uma correção resolveu o risco
Um risco identificado precisa de informações suficientes para orientar o tratamento: a operação afetada, as condições da avaliação, o comportamento observado e o resultado esperado.
Depois da correção, o mesmo caso passa por uma nova avaliação. No exemplo da transferência, isso significa verificar se o valor acima do limite voltou a ser recusado. Conforme o alcance da alteração, também pode ser necessário avaliar condições próximas, como operações dentro do limite.
Esse reteste confirma o efeito da correção sobre o comportamento encontrado e deixa o resultado registrado para as equipes responsáveis.
Como o ARC apoia a reavaliação de APIs
O R/Pulse API Resilience Core (ARC) realiza validações de APIs críticas para identificar riscos e apoiar seu tratamento. Ele acompanha as mudanças na especificação e direciona novas validações para o que mudou.
Quando encontra um risco, apresenta o comportamento observado e evidências para reprodução, com indicação de prioridade. Depois do tratamento, uma nova avaliação verifica se o comportamento identificado continua ocorrendo.
Conclusão
Um teste aprovado na versão anterior não garante nada sobre a versão atual. Basta que permissões, integrações ou regras tenham mudado no caminho. A transferência de R$ 8 mil do início passaria em qualquer checagem de disponibilidade ou de contrato.
O que encontra esse tipo de falha é reavaliar as regras de negócio junto com cada mudança relevante. Com isso, o time sabe se a mudança pode avançar, o que precisa de correção e quais comportamentos ainda pedem investigação.
Conheça o R/Pulse ARC e converse com nosso time sobre a validação das suas APIs.