Glossário
O que é IDOR — ver os dados de outra pessoa só trocando um ID
O IDOR (controle de acesso quebrado) permite trocar um ID numa URL ou parâmetro e alcançar dados que não são seus. Como funciona e a defesa de verdade: verificar no servidor, a cada requisição, se este usuário pode acessar este objeto.
"Troquei id=124 por 125 na URL e a fatura de outra pessoa apareceu" — isso é IDOR (controle de acesso quebrado). Veja como funciona e como preveni-lo de forma confiável (sem passos de ataque).
Por que acontece
A autenticação (quem você é) passa, mas a autorização (você pode fazer isto?) está ausente. Autenticação e autorização são coisas diferentes — conseguir logar não significa ter permissão para ver aqueles dados.
| Brecha comum | Resultado |
|---|---|
| Confiar no ID como está depois do login | Troque pelo ID de outro usuário e ele passa direto |
| Erro do "não mostrado na interface = seguro" | Chamar a API diretamente está totalmente aberto |
| Sem verificação de permissão em criar/atualizar/excluir | Não só visualizar — adulteração e exclusão também |
Por que funciona
Defesa: verifique posse/permissão no servidor, sempre
Verifique posse/permissão por objeto (o mais importante)
Logo antes de retornar ou modificar dados, verifique no servidor que o usuário logado possui ou tem permissão sobre aquele objeto. Negue se não.
Negue por padrão
Novos endpoints partem de "negar tudo, exceto o que é explicitamente permitido", para que uma verificação esquecida falhe fechada, não aberta.
Consulte apenas as linhas 'suas'
Embuta a condição de posse na própria consulta (por exemplo, filtre pelo id do usuário atual). Roteie tudo por um único helper de autorização compartilhado para que nenhum ponto de chamada o esqueça.
Não confunda controle de interface com defesa
Ocultar um botão é UX, não segurança. Suponha que a API é chamada diretamente e decida apenas no servidor. Mantenha IDs aleatórios como auxílio, não como o controle.
A visão deste site: despretensioso, mas de impacto máximo — proteja com testes
O IDOR é tecnicamente sem graça e facilmente esquecido em revisão de código, mas o impacto é de primeira linha ("um clique revela os dados pessoais de todos"). Então o movimento prático é travar um teste automatizado: como outro usuário, atingir o ID de outra pessoa deve retornar 403. O princípio deste site é "nunca defender na interface do cliente; decidir apenas no servidor". A autorização deve ser imposta por um mecanismo a cada requisição — nunca deixada à atenção humana.
Leia a seguir
- Glossário: O que é CSRF (autenticação vs autorização)
- Fundamentos: Fundamentos de segurança · Ferramentas de segurança gratuitas
FAQ
QO que acontece com o IDOR?
Um usuário logado troca um ID numa URL ou API (?id=124 por outro valor) e visualiza, edita ou apaga a fatura, o pedido, os dados pessoais ou os arquivos de outra pessoa. É o carro-chefe da classe de problema mais comum (controle de acesso quebrado) e assusta porque não precisa de ferramentas especiais.
QQual é a principal defesa?
A cada requisição, no servidor, verifique 'ESTE usuário logado pode agir sobre ESTE objeto?'. Mesmo que o ID seja bem formado, verifique posse/permissão e negue se ausente (negar por padrão). Nunca confie em ocultar na interface do cliente.
QUUIDs ou IDs aleatórios previnem isso?
Eles só tornam os IDs mais difíceis de adivinhar — não são uma correção de verdade. Se um ID vazar ou for compartilhado, ele passa direto. Mantenha a aleatorização como auxílio; a defesa de verdade é sempre uma verificação de posse/permissão no servidor.