O que é IDOR
IDOR é a sigla de Insecure Direct Object Reference, também chamado de BOLA (Broken Object Level Authorization) quando é uma API. Na prática: o sistema identifica um recurso (um pedido, um contrato, um arquivo) por um ID, e alguma rota devolve ou modifica esse recurso só checando se o ID existe, sem checar se ele pertence a quem está pedindo.
É provavelmente a falha mais comum, e mais barata de corrigir, em qualquer SaaS ou marketplace multi-tenant. E também uma das mais fáceis de explorar: muitas vezes basta trocar um número na URL ou no corpo da requisição.
O caso
Num marketplace B2B, uma rota que devolvia o detalhe de um pedido aceitava o ID do pedido diretamente na requisição, e devolvia os dados sem verificar se aquele pedido pertencia à empresa autenticada. Trocando o ID por outro valor sequencial, era possível visualizar pedidos de outros clientes da plataforma: itens comprados, valores negociados, dados de contato.
Não precisou de ferramenta sofisticada nem de exploração complexa. Só precisou alguém tentar um ID que não era o seu, e reparar que o sistema respondia mesmo assim.
Por que isso acontece tanto
Geralmente porque a checagem de propriedade existe no frontend (o menu só mostra os pedidos do próprio usuário) mas não existe de novo no backend, na rota que efetivamente devolve o dado. O frontend nunca é uma barreira de segurança: qualquer requisição pode ser refeita direto pra API, ignorando toda a interface.
A causa raiz quase sempre é a mesma: o backend confia no ID que veio na requisição, em vez de comparar esse ID com o que o token de autenticação autoriza.
Como isso se previne
- Toda rota que recebe um ID de recurso precisa verificar, no backend, se aquele recurso pertence ao usuário ou tenant autenticado, nunca confiar só na existência do ID.
- O ID do tenant ou usuário usado pra essa checagem vem do token assinado da sessão, nunca de um campo que o próprio cliente manda na requisição.
- Testar deliberadamente trocando IDs de recurso durante o desenvolvimento, não só depois que o sistema já está em produção.
É uma correção simples de implementar. O difícil é lembrar de aplicar essa checagem em toda rota nova que alguém escreve, meses depois que o padrão original foi definido, o que é exatamente o tipo de coisa que um pentest recorrente pega antes de virar incidente.
Sua API valida quem é dono de cada recurso, em toda rota?
Solicitar Pentest em APIs