Revise uma falha de controle de acesso

Use identidades de teste com e sem propriedade para distinguir autenticação de autorização no objeto.

A autenticação identifica quem faz a chamada. A autorização decide se essa pessoa pode executar a operação naquele objeto. Uma sessão válida não comprova que o objeto pertence ao usuário.

Este fluxo acompanha um endpoint de relatórios sintéticos. Separe as operações de leitura e escrita: comprovar uma falha de leitura não significa que também seja possível alterar ou excluir.

Antes de começar

  • Duas contas ou tenants sintéticos, A e B, e um relatório criado por A.
  • O handler, os helpers de autorização e o campo de propriedade do objeto, quando houver código disponível.
  • A política esperada para dono, outro usuário, acesso anônimo e acesso privilegiado.

Siga as etapas

  1. Capture a requisição e resposta bem-sucedidas de A como referência. Registre o campo exato que demonstra acesso ao conteúdo do relatório.
  2. Repita a operação como B, alterando apenas a sessão. Teste o acesso anônimo separadamente e evite caches que confundam a fronteira de identidade.
  3. Siga a busca no servidor. Confira se o filtro inclui o tenant atual ou se uma política posterior rejeita quem não é dono.
  4. Escreva testes para o sucesso de A e o bloqueio de B. Só adicione um caso privilegiado se o produto realmente definir essa exceção.
  5. Revise o patch e execute os testes. Confira endpoints alternativos, recursos aninhados e respostas de erro para a mesma regra.

Use um prompt preciso

Adapte às suas evidências
Revise a busca do relatório e seus chamadores conforme esta política: o tenant da sessão deve ser dono do relatório. Mostre a decisão de autorização separada da autenticação. Se um objeto puder atravessar tenants, proponha um teste de regressão e a menor correção no servidor. Identifique exceções de papel que exijam uma decisão de produto.

Verifique seu trabalho

  • O teste comprova acesso ao objeto protegido, não apenas uma resposta 200.
  • Uma sessão nova de quem não é dono é bloqueada após a correção, e o acesso válido continua funcionando.
  • O servidor impõe a regra independentemente de botões ocultos, estado do cliente ou identificadores imprevisíveis.

Leve suas evidências para uma conversa e avance para a próxima pergunta.

Abrir chat