IDOR (controle de acesso quebrado) é quando trocar id=124 por 125 numa URL mostra a fatura de outra pessoa. 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 o acesso funciona |
| Erro do "não mostrado na interface = seguro" | Chamar a API diretamente não é bloqueado |
| Sem verificação de permissão em criar/atualizar/excluir | Não só visualizar — adulteração e exclusão também |
Por que funciona
IDs não aparecem só como ?id= numa URL. Caminhos de API (/api/orders/125), corpos JSON ("userId": 125), URLs de download de arquivos e campos ocultos de formulário precisam da mesma verificação — em qualquer lugar onde um valor enviado pelo usuário escolhe sobre qual objeto agir.
Termos relacionados
O IDOR é uma forma de controle de acesso quebrado. Ele tem vários nomes e é fácil de confundir com seus vizinhos.
| Termo | O que falta | Exemplo |
|---|---|---|
| IDOR | Verificação de posse/permissão por objeto | O usuário A troca um ID e vê a fatura do usuário B |
| BOLA | O mesmo que IDOR (nome usado pelo OWASP API Security) | /orders/{id} numa API devolve o pedido de outra pessoa |
| Falha de autorização por função | Verificação de permissão por função | Um usuário comum consegue chamar uma API só para administradores |
| Autenticação quebrada | A própria verificação de "quem é você" | A API pode ser chamada sem login |
No OWASP Top 10, o Controle de Acesso Quebrado (A01) está em primeiro lugar na edição de 2025, como em 2021. No OWASP API Security Top 10 (2023), focado em APIs, o BOLA também é o primeiro (API1:2023).
Casos reais: dados de outras pessoas visíveis após o login
Dois casos do setor público que este site cobriu foram atribuídos oficialmente a defeitos introduzidos em atualizações de sistema, mas o resultado teve a mesma forma de uma falha de autorização: um usuário logado conseguia alcançar dados que não eram seus.
- Companies House, do Reino Unido (março de 2026): usuários logados no WebFiling podiam, por certas ações, potencialmente ver endereços residenciais de diretores de outras empresas e outros dados, e registros não autorizados eram tecnicamente possíveis. O órgão diz que foi um defeito introduzido numa atualização de sistema de outubro de 2025, não um ataque externo → análise completa (em inglês)
- e-Tax da Agência Nacional de Impostos do Japão (setembro de 2026): um defeito de uma atualização da página "My Page" permitiu que outros usuários vissem declarações de imposto sobre doações e documentos relacionados de 79 pessoas → análise completa (em inglês)
Nos dois casos, a verificação de login funcionava. O que faltava era "este usuário pode agir sobre este objeto?". E ambos aconteceram depois de uma mudança. Mesmo um sistema correto pode perder a verificação quando um recurso é adicionado, e por isso vale ter um teste automatizado que rode sempre.
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.
Como verificar o seu próprio app
Faça isto apenas num app que você desenvolve ou administra. Tentar no serviço de outra pessoa pode ser acesso não autorizado.
- Crie os usuários de teste A e B e dê a cada um um registro (um pedido, um arquivo etc.)
- Logado como A, chame as APIs de visualizar, atualizar e excluir com um ID que aponte para o registro de B. Chame a API diretamente pelas ferramentas de desenvolvedor ou por um cliente de API, não pela interface
- Confirme que todas as requisições são recusadas com 403 ou 404. Verifique também que os endpoints de listagem não incluem registros de B
- Transforme isso num teste automatizado e adicione o mesmo teste sempre que criar um endpoint
O OWASP API Security Top 10 também recomenda escrever testes que avaliem o mecanismo de autorização e não publicar mudanças que façam esses testes falharem.
A visão deste site: fácil de passar despercebido, mas de alto impacto, então verifique com testes automatizados
O IDOR é tecnicamente sem graça e facilmente esquecido em revisão de código, mas o impacto é grave ("um clique revela os dados pessoais de todos"). Então o movimento prático é adicionar um teste automatizado: como outro usuário, solicitar 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.
Fontes (primárias)
- OWASP Top 10:2025, "A01 Broken Access Control" — top10.owasp.org (em inglês; classificação; o exemplo de referências diretas inseguras a objetos)
- OWASP API Security Top 10 2023, "API1:2023 Broken Object Level Authorization" — api-security.owasp.org (em inglês; prevenção; recomendação de testes)
- MITRE CWE-639: Authorization Bypass Through User-Controlled Key — cwe.mitre.org (em inglês)
- As fontes dos dois casos (comunicados da Companies House e da Agência Nacional de Impostos) estão listadas em cada análise
Leia a seguir
- Fundamentos: Autenticação vs. autorização (fazer login ≠ autorização; IDOR é uma forma dessa autorização ausente)
- Casos: Falha no WebFiling da Companies House (em inglês) · Declarações de imposto sobre doações visíveis a outros usuários no e-Tax (em inglês)
- Glossário: O que é CSRF (ataque que abusa da sua sessão logada) · O que é o OWASP Top 10 · O que é session fixation
- Fundamentos: Fundamentos de segurança · Ferramentas de segurança gratuitas