Você entra no painel, abre seu pedido e vê uma URL terminando em /pedidos/123. Aí troca o 123 por 124 e o sistema entrega a compra de outra pessoa. Não houve invasão cinematográfica, nem uma senha quebrada. O servidor simplesmente confiou demais no identificador que veio do navegador.
Esse tipo de falha tem nome: IDOR, sigla em inglês para Insecure Direct Object Reference. A OWASP descreve o problema como o acesso ou a alteração de um objeto porque a aplicação não confirmou se aquele usuário tinha permissão para lidar com ele. O objeto pode ser uma conta, um documento, um chamado de suporte, uma transação ou qualquer registro protegido.
A parte que costuma confundir quem está começando é esta: autenticação e autorização são coisas diferentes. Autenticação responde quem você é. Autorização responde o que você pode fazer. O usuário pode estar devidamente logado e ainda assim não ter direito de abrir o documento de outro cliente.
Como o IDOR aparece em uma URL
Imagine uma API que responde a GET /usuarios/123. O controlador recebe o número, busca o registro no banco e devolve os dados. Se a consulta for algo como "busque o usuário cujo id é 123", sem relacionar esse registro ao usuário autenticado, qualquer pessoa que descubra outro identificador pode tentar a mesma chamada.
O número é apenas um exemplo. A referência pode ser um UUID, um nome de arquivo, um slug, um número de pedido ou um código escondido em um formulário. A própria OWASP mostra que um arquivo como annual-report.pdf também pode funcionar como referência direta. Trocar o nome por outro arquivo válido não deveria abrir um documento que pertence a outra conta.
Também não é preciso haver uma tela bonita para a falha existir. Ela pode estar em uma requisição POST que recebe user_id em um campo oculto, em uma rota de download ou em um endpoint usado apenas pelo aplicativo mobile. Se o servidor aceita o identificador e não faz a checagem de objeto, esconder o campo no HTML não protege nada.
O que o servidor precisa confirmar
A correção começa no lugar certo: no servidor. A aplicação deve identificar o usuário autenticado, carregar o objeto solicitado e verificar se aquela pessoa tem uma relação válida com o objeto. Em um sistema simples, isso pode ser uma comparação de propriedade: o pedido pertence ao usuário atual? Em um sistema maior, a regra pode envolver equipe, organização, papel ou uma permissão específica.
Essa verificação deve acontecer em toda operação relevante, não apenas na tela que lista os registros. Ler, editar, apagar, baixar e exportar são ações diferentes. Um usuário pode visualizar um chamado, mas não alterar sua prioridade. Outro pode editar dados da própria organização, mas não acessar a organização vizinha. A regra precisa acompanhar a ação, não o caminho visual que levou até ela.
Usar identificadores difíceis de adivinhar ajuda a reduzir tentativas casuais, mas não corrige o IDOR. Um UUID vazado continua sendo um UUID autorizado de forma errada. A defesa não pode depender de o atacante não descobrir o valor. O teste decisivo é outro: mesmo conhecendo o identificador, uma conta sem permissão recebe uma resposta negada?
Como testar sem expor dados reais
O teste mais seguro usa pelo menos duas contas fictícias com permissões diferentes. Crie um registro para a conta A, capture a requisição feita por A e repita a chamada como B, trocando apenas o identificador do objeto. A conta B deve receber uma resposta negada ou uma resposta que não revele se o registro existe, conforme a política do sistema.
Repita o exercício para cada verbo e cada tipo de referência. Tente consultar, editar, apagar e baixar. Troque números, UUIDs, slugs e nomes de arquivo. Teste também objetos pertencentes a outra organização e usuários com papéis diferentes. O objetivo não é forçar o sistema em produção; é criar uma matriz pequena de casos previsíveis em ambiente de teste.
Registre o resultado com dados fictícios, código do endpoint e permissão esperada. Uma resposta HTTP 200 não é automaticamente sucesso: o corpo pode estar vazio ou mascarar a ausência de autorização. Da mesma forma, retornar 404 ou 403 pode ser uma decisão válida, desde que o sistema não vaze informações por mensagens, tempos de resposta ou metadados.
Checklist para revisar uma API
Antes de colocar um recurso no ar, pergunte qual é o objeto protegido, quem é o dono e qual regra permite a ação. Procure consultas que filtram apenas pelo identificador recebido do cliente. Veja se a autorização é aplicada no serviço ou controlador que realmente executa a operação, e não apenas na interface.
Depois, escreva testes de negação. Para cada endpoint que recebe um identificador, confirme que uma conta diferente não consegue ler ou alterar o recurso. Inclua cenários de organização, equipe e papel. Se houver arquivos, teste o download direto. Se houver exportação, verifique se o filtro aplicado à tela também é aplicado ao arquivo gerado.
Por fim, trate registros históricos, logs e caches com o mesmo cuidado. Uma API pode bloquear a página principal e ainda deixar uma resposta antiga acessível em outro endpoint. A revisão precisa seguir o dado por todo o fluxo. Se a regra de autorização ficar espalhada em muitos pontos, vale centralizar a política para que novos endpoints não nasçam sem a mesma proteção.
IDOR parece uma falha pequena porque o exemplo cabe em uma URL. O impacto não é pequeno quando o objeto contém dados pessoais, documentos, cobranças ou informações internas. A regra prática é simples: o identificador diz qual objeto foi pedido; ele nunca decide sozinho se o objeto pode ser entregue. Para aprofundar a revisão, consulte a orientação da OWASP sobre prevenção de IDOR e adapte os testes ao modelo de permissão da sua aplicação.
