Controle de acesso

O que é IDOR?

O conceito em um exemplo

Imagine uma área autenticada na qual cada cliente consulta uma fatura por uma URL como /faturas/1042. O número identifica um objeto interno. Se trocar 1042 por 1043 retorna a fatura de outra pessoa, o problema não é o número ser previsível: é a ausência de uma verificação de autorização para aquele objeto.

O identificador também pode aparecer em parâmetros, cabeçalhos ou no corpo de uma API. Pode ser um número, UUID, nome de arquivo ou qualquer outra chave. Um identificador difícil de adivinhar reduz enumeração, mas não substitui autorização.

Autenticação não é autorização

Autenticação responde “quem é você?”. Autorização responde “o que você pode fazer?”. Uma sessão válida não autoriza automaticamente o usuário a consultar todo registro que o endpoint consegue localizar.

Por isso, a validação deve ocorrer no servidor em cada operação de leitura, alteração ou exclusão. Esconder um botão na interface ou confiar no identificador enviado pelo navegador não resolve.

Como prevenir

• Vincule a busca ao usuário ou tenant (organização) autenticado, em vez de buscar apenas pelo ID.
• Aplique negação por padrão e valide a permissão em toda requisição.
• Centralize regras de autorização para evitar comportamentos diferentes entre endpoints.
• Use identificadores não sequenciais como camada adicional, nunca como defesa principal.
• Crie testes automatizados com usuários e perfis diferentes.

Como verificar com segurança

Em um ambiente autorizado, use duas contas de teste. Crie um objeto com a primeira, copie sua referência e tente consultá-lo com a segunda. Repita o teste para leitura, edição e exclusão. O resultado esperado é uma resposta de acesso negado ou recurso não encontrado, sem revelar dados.

Faça esse tipo de teste apenas em sistemas próprios, laboratórios ou programas que tenham autorizado explicitamente a avaliação.

Referência

A OWASP mantém um guia de prevenção de IDOR com exemplos e recomendações para desenvolvimento seguro.