A autorização de APIs falha silenciosamente: teste cada objeto, função e ação

Em resumo: A autenticação comprova quem fez a solicitação; a autorização decide o que essa identidade pode fazer. A segurança de APIs falha quando as equipes testam a primeira pergunta e presumem que a segunda funciona em todos os lugares.

Um token válido não é um recibo de permissão

As APIs modernas geralmente colocam uma autenticação forte diante de controles fracos no nível do objeto. Uma solicitação pode conter uma sessão ou token de acesso perfeitamente válido e ainda pedir a fatura, o projeto, a exportação ou uma ação administrativa de outro cliente. Se o controlador verificar apenas se o chamador está autenticado, a API respondeu à pergunta de segurança errada.

Essa falha é fácil de passar despercebida porque os testes normais do produto seguem o caminho pretendido. O proprietário abre o registro do proprietário, um administrador usa um endpoint de administrador e cada solicitação é bem-sucedida exatamente como esperado. Os defeitos de autorização aparecem apenas quando a identidade, o objeto, o inquilino ou a ação são deliberadamente incompatíveis.

Crie uma matriz de autorização completa

• Teste cada operação de objeto como proprietário, outro usuário do mesmo locatário, um usuário de outro locatário e um chamador não autenticado.
• Teste de forma independente as ações de leitura, criação, atualização, exclusão, exportação, convite e aprovação; proteger um método não prova que os demais estejam protegidos.
• Altere identificadores em caminhos, parâmetros de consulta, corpos JSON, cabeçalhos e objetos aninhados em vez de testar apenas o campo de URL óbvio.
• Verifique transições de função e sessões obsoletas para que usuários rebaixados ou removidos não possam reter privilégios por meio de declarações armazenadas em cache.

Negar por padrão no limite de dados

O design mais confiável vincula cada consulta ao objeto solicitado e ao escopo autorizado do chamador. Buscar um registro por identificador e verificar a propriedade posteriormente cria espaço para verificações esquecidas, canais secundários e tratamento de erros inconsistente. A consulta dentro do inquilino ou do limite de propriedade torna a condição segura parte da própria recuperação.

Funções centralizadas de política reduzem inconsistências, mas não substituem os testes. Cada endpoint ainda precisa de verificações negativas que provem que identidades proibidas não recebem dados nem alteram o estado. Uma resposta 403 só é uma evidência útil quando o banco de dados e os efeitos colaterais posteriores permanecem intactos.

As evidências devem provar que o caminho proibido permaneceu fechado

Um teste de autorização útil captura o chamador, a função, o locatário, o objeto de destino, a solicitação, a resposta e o estado pós-solicitação. Essa evidência distingue um controle real de uma restrição front-end ou de um código de status que mascara uma ação que já aconteceu.

O KENSAI trata a validação do controle de acesso como uma matriz, não como uma única verificação do fluxo esperado. O objetivo é provar o isolamento entre identidades e ações e preservar evidências suficientes para reproduzir qualquer falha de limite e verificar sua correção.

Conclusão

Autorização é um relacionamento entre uma identidade, um objeto e uma ação. Teste todas as três dimensões com casos negativos e prove que solicitações proibidas não produzem exposição de dados nem efeitos colaterais.