O controle de acesso quebrado é a falha que deixa uma aplicação fazer o que deveria ter impedido: ler os dados de outro usuário, alcançar uma página de administração nunca autorizada, ou editar um registro que pertence a outra pessoa. Ele ocupa o primeiro lugar do OWASP Top 10 porque está ao mesmo tempo em toda parte e é fácil de passar despercebido. O jeito mais rápido de entender é quebrar um você mesmo, então abra o lab IDOR Explorer da HackerDNA e troque um ou dois identificadores enquanto lê.
Esse risco conquistou o primeiro lugar do OWASP Top 10 e o manteve na edição de 2025, que até incorporou o Server-Side Request Forgery como um subcaso. Este guia cobre o que é o controle de acesso quebrado, os principais tipos que você encontrará (inclusive o IDOR), como o ataque funciona passo a passo, como testá-lo e como neutralizá-lo no seu próprio código.
Resumo: o controle de acesso quebrado acontece quando uma aplicação autentica um usuário mas nunca verifica se ele está autorizado para a ação ou o registro específico que solicitou. A forma mais comum é o IDOR: troque id=1043 por id=1044 e leia a fatura de um desconhecido. A correção não é um filtro melhor, é uma verificação de autorização no servidor em cada requisição, vinculada ao usuário logado, negando por padrão. Você aprende a identificá-lo explorando-o, então pratique em um lab no navegador antes de tentar se defender dele.
O que é controle de acesso quebrado?
O controle de acesso quebrado é uma vulnerabilidade web em que uma aplicação não impõe corretamente o que um usuário autenticado tem permissão de ver ou fazer. O usuário faz login sem problema, mas a aplicação então lhe confia dados ou ações que deveriam ser restritos, porque a verificação de autorização está ausente, é fraca ou é aplicada no lugar errado.
A distinção fundamental é entre autenticação e autorização. A autenticação responde "quem é você?" e a maioria das aplicações acerta. A autorização responde "você tem permissão de fazer esta coisa específica?" e é aí que elas falham. Uma aplicação pode saber exatamente quem você é e ainda assim lhe entregar o painel de administração, porque ninguém escreveu a verificação que diz que você não é administrador.
É essa lacuna que torna esta classe tão comum. Os sistemas de login são testados por cada desenvolvedor e cada scanner. As verificações de permissão por objeto e por ação ficam espalhadas por centenas de endpoints, e basta um único endpoint que esqueceu de perguntar "este registro pertence a quem chamou?" para vazar a tabela inteira. Os dados da OWASP confirmam isso: o controle de acesso quebrado foi encontrado em mais aplicações testadas do que qualquer outra categoria, o que explica exatamente seu primeiro lugar.
Onde ele aparece
- Referências de objetos - URLs e chamadas de API que carregam um identificador de registro (
/account?id=17) em que o servidor confia sem verificar a propriedade. - Funções administrativas e privilegiadas - endpoints de gerenciamento que dependem de um link oculto em vez de uma verificação real de papel.
- Endpoints de API - rotas REST e GraphQL que impõem o acesso na interface mas não no servidor, de modo que uma requisição direta passa reto por elas.
- Recursos estáticos e internos - arquivos, relatórios e backups acessíveis ao adivinhar um caminho que o menu nunca exibiu.
Como funciona um ataque de controle de acesso quebrado
Um ataque de controle de acesso quebrado tem três partes móveis: uma sessão válida, uma referência ou ação que você não deveria controlar, e um servidor que verifica a identidade mas não a permissão. O fluxo é curto.
- Faça login como um usuário comum. Você precisa de uma sessão legítima para alcançar recursos autenticados. Isso não é um contorno de autenticação, você é um usuário comum abusando do que já pode tocar.
- Encontre uma referência que você possa mudar. Procure um identificador, nome de usuário, nome de arquivo ou valor de papel na URL, em um cookie, em um campo de formulário oculto ou em um corpo JSON. Tudo o que o cliente envia e sobre o que o servidor age é um candidato.
- Mude-a e observe a resposta. Incremente o identificador, troque seu nome de usuário por outro, passe
role=userpararole=admin. Se o servidor devolver dados ou executar uma ação que deveria ter sido negada, o controle de acesso está quebrado.
Considere uma aplicação que serve seu perfil em GET /api/user/2001/details. O servidor confirma que você está logado e então devolve o identificador de usuário presente no caminho. Envie GET /api/user/2002/details e, em uma aplicação vulnerável, você recebe os detalhes da próxima pessoa. Você nunca quebrou o login, apenas pediu algo a que não deveria ter direito, e o servidor disse sim.
Ao testar aplicações reais, a primeira coisa que vale a pena fazer é capturar duas contas. Faça login como usuário A, registre uma requisição que toque os dados de A e, então, repita-a com a sessão de A mas o identificador de B. Se A conseguir ler ou alterar os recursos de B, você tem uma falha de controle de acesso confirmada, com uma prova limpa e reproduzível, que é exatamente o que um relatório precisa.
Tipos de controle de acesso quebrado
O controle de acesso quebrado é uma categoria, não um bug único. Estas são as formas que você realmente vai encontrar, mais ou menos em ordem de frequência nos testes reais.
Referência Direta Insegura a Objeto (IDOR)
Um IDOR expõe uma referência interna (um identificador de banco de dados, nome de arquivo ou chave) e deixa um usuário trocá-la por uma que não possui. É o retrato desta categoria e ganha sua própria seção mais adiante justamente por ser tão comum.
Escalação vertical de privilégios
É um usuário de baixo privilégio alcançando funções de alto privilégio. Uma conta comum capaz de carregar /admin/users ou chamar uma API restrita a administradores escala verticalmente, subindo a ações reservadas a um papel superior.
Escalação horizontal de privilégios
Aqui você permanece no mesmo nível de privilégio mas alcança os dados de um colega. O usuário A lendo as mensagens do usuário B é escalação horizontal. A maioria dos IDORs é horizontal: mesmo papel, proprietário diferente, nenhuma verificação de que o proprietário é você.
Navegação forçada e ausência de controle no nível da função
Algumas aplicações escondem uma página simplesmente não a vinculando, supondo que ninguém achará a URL. Isso é segurança por obscuridade, e ela cai no momento em que alguém adivinha /admin, o lê no JavaScript ou o encontra no mapa do site. Se o servidor não verifica o papel ao carregar a página, o link oculto era a única fechadura.
Adulteração de metadados e de método
Decisões de acesso baseadas em dados controlados pelo cliente caem quando o cliente muda esses dados. Um JWT com "role":"user" em que o servidor confia sem verificar a assinatura, um cabeçalho X-Original-URL que contorna uma verificação de caminho, ou um endpoint que bloqueia POST mas não PUT são todos falhas de controle de acesso disfarçadas de detalhes de protocolo.
IDOR: a falha de controle de acesso mais comum
A Referência Direta Insegura a Objeto (IDOR) é uma falha de controle de acesso em que uma aplicação usa um valor fornecido pelo usuário para buscar um objeto diretamente, sem verificar se o solicitante tem permissão de acessar aquele objeto. Mude o valor, obtenha um objeto diferente. Ela corresponde a CWE-639 e é a forma de falha de controle de acesso mais reportada em programas de bug bounty.
O caso clássico é a fatura. Você consulta a sua em /invoice?id=1043, muda o número para 1044, e a aplicação lhe entrega a de outra pessoa, porque verificou que você estava logado mas nunca verificou que a fatura 1044 era sua. A mesma forma aparece com nomes de usuário (/profile/alice vira /profile/bob), nomes de arquivo (/download?file=report_2024.pdf) e caminhos de API (/api/orders/58210).
O IDOR é perigoso justamente porque é entediante de explorar. Não há payload esperto, nem truque de codificação, nem condição de corrida. Você incrementa um número. Esse baixo esforço explica por que uma enumeração automatizada de identificadores com uma ferramenta como o Burp Intruder pode extrair milhares de registros de um único endpoint vulnerável em minutos, e por que um IDOR sobre um objeto sensível é frequentemente classificado como gravidade alta ou crítica.
Uma defesa comum na qual você não deve confiar é trocar identificadores sequenciais por UUIDs. Identificadores aleatórios tornam a adivinhação mais difícil, o que eleva a barreira, mas não são autorização. Se um UUID vazar por um cabeçalho referer, uma exportação ou um link compartilhado, e o servidor ainda não verificar a propriedade, o IDOR permanece intacto. UUIDs são um quebra-molas, não um controle.
Como testar o controle de acesso quebrado
Como se testa o controle de acesso quebrado? Faça login com duas contas separadas, capture as requisições que uma conta faz a seus próprios recursos e, então, repita essas requisições usando a sessão da outra conta e os identificadores de outra pessoa. Se o servidor devolver dados ou executar ações que deveria ter bloqueado, o controle de acesso está quebrado. Os scanners automatizados perdem a maioria desses casos, porque só um humano sabe qual registro deveria ter pertencido a quem.
Uma metodologia prática é assim:
- Mapeie cada papel. Liste os níveis de privilégio (anônimo, usuário, administrador) e obtenha uma conta de teste para cada um. O controle de acesso é relativo, então você precisa de algo para comparar.
- Cataloge as referências. Percorra a aplicação com o proxy do Burp Suite ativo e anote cada identificador, nome de usuário, nome de arquivo e valor de papel que o cliente envia. Cada um é um caso de teste.
- Troque e repita. Pegue uma requisição da conta A e reenvie-a com a sessão de A mas o identificador de B. Depois tente sem sessão nenhuma. Fique atento a um
200onde você esperava um403. - Teste os métodos e as brechas da interface. Se
POST /admin/deleteestiver bloqueado, tentePUTouDELETE. Se um botão estiver desabilitado no cliente, envie mesmo assim a requisição que ele teria enviado.
Na prática, a descoberta que mais surpreende as equipes é a API de administração "oculta". O front-end nunca mostra o controle a um usuário comum, então todos o supõem seguro, mas o endpoint responde a uma requisição direta de qualquer conta logada. A interface fazia o controle de acesso que o servidor esqueceu de fazer. Esse é o rosto cotidiano desta vulnerabilidade.
Como prevenir o controle de acesso quebrado
Como se previne o controle de acesso quebrado? Imponha a autorização no servidor para cada requisição, negue por padrão e vincule cada decisão de acesso à sessão autenticada em vez de a qualquer valor que o cliente envie. Nunca confie em ocultar um link ou desabilitar um botão, porque o cliente está totalmente sob controle do atacante.
Sobreponha estes controles, já que o controle de acesso é uma disciplina, não uma correção única:
- Negue por padrão. Cada recurso começa fechado. O acesso só é concedido por uma regra explícita, de modo que um novo endpoint que alguém esqueceu de proteger fica trancado, não aberto.
- Verifique a propriedade no servidor, toda vez. Antes de devolver o objeto 1044, confirme que a sessão atual possui o objeto 1044. Faça isso no backend, em cada requisição, não uma única vez no gateway. É o controle que realmente detém o IDOR.
- Nunca confie na identidade do lado do cliente. Derive o usuário da sessão do servidor, não de um parâmetro de URL, campo oculto ou token não verificado. Se um JWT carrega um papel, verifique sua assinatura antes de acreditar em qualquer alegação nele.
- Centralize a lógica. Uma única camada de autorização por onde cada requisição passa vale mais do que verificações por endpoint copiadas à mão, porque as cópias divergem e uma delas estará errada.
- Registre as falhas de acesso e limite a taxa. Uma enxurrada de respostas
403em identificadores crescentes é um ataque de enumeração em andamento. Registre-o e limite-o.
A mitigação que as equipes mais erram é verificar o acesso na camada errada. Um gateway que confirma que você está logado não é o mesmo que um serviço que confirma que você possui o registro, e colocar a única verificação na borda deixa cada chamada interna sem guarda. Valide a propriedade onde o dado é servido, vinculada à sessão, e a classe inteira em grande parte se fecha.
O controle de acesso quebrado no OWASP Top 10
O controle de acesso quebrado é a entrada número um desde a edição de 2021 e manteve essa posição no OWASP Top 10 2025. Ele se classifica em primeiro com base nos dados: a OWASP encontrou alguma forma de fraqueza de controle de acesso em uma parcela maior de aplicações testadas do que qualquer outra categoria, e o impacto vai de ler um registro a mais até a tomada administrativa total.
A revisão de 2025 ampliou a categoria. O Server-Side Request Forgery, que tinha seu próprio décimo lugar em 2021, foi reclassificado como um subcaso do controle de acesso quebrado, sob o argumento de que o SSRF é fundamentalmente o servidor fazendo uma requisição que nunca foi autorizado a fazer. Se o ângulo do SSRF lhe interessa em particular, nosso guia do ataque SSRF cobre os alvos de metadados de nuvem e serviços internos que o tornam perigoso.
Para o mapa completo de onde esse risco fica entre os dez e do que mudou entre as listas de 2021 e 2025, nosso guia OWASP Top 10 percorre cada categoria com um exemplo concreto. As falhas de controle de acesso também se sobrepõem às falhas de injeção na prática, então vale a pena lê-lo ao lado do nosso tutorial de injeção SQL, onde uma única consulta pode extrair registros que nenhum usuário deveria alcançar.
Considerações legais e éticas
Lembrete essencial: obtenha sempre autorização escrita explícita antes de testar qualquer sistema em busca de controle de acesso quebrado. Mudar um identificador para ler os dados de outro usuário em um alvo que não é seu constitui acesso não autorizado sob o Computer Fraud and Abuse Act (EUA), o Computer Misuse Act (Reino Unido) e leis equivalentes no mundo todo, mesmo quando a mudança é tão pequena quanto digitar um número diferente.
- Teste apenas em sistemas que você possui, em labs dedicados, ou dentro do escopo definido de um engajamento autorizado.
- Um IDOR que devolve dados reais de usuário significa que você acessou as informações pessoais de outra pessoa. Pare na prova de impacto, não baixe em grande escala, e reporte imediatamente.
- "A URL me deixou" não é uma defesa jurídica. A autorização vem da permissão do proprietário, não do fato de o servidor ter respondido.
- Pratique em alvos propositalmente vulneráveis, não em aplicações reais encontradas por acaso. Os labs abaixo existem exatamente para isso.
Perguntas frequentes
O que é controle de acesso quebrado em termos simples?
O controle de acesso quebrado é quando uma aplicação deixa um usuário logado fazer algo que não deveria poder fazer, como visualizar a conta de outra pessoa ou alcançar uma página de administração. A aplicação verifica quem você é mas esquece de verificar se você tem permissão de executar aquela ação específica, então entrega dados ou poderes que deveriam ser restritos.
Qual é a diferença entre controle de acesso quebrado e IDOR?
O controle de acesso quebrado é a ampla categoria das falhas de autorização. O IDOR (Referência Direta Insegura a Objeto) é um tipo específico dentro dela, em que mudar uma referência como um identificador ou nome de arquivo lhe dá acesso a um objeto que você não possui. Todo IDOR é uma falha de controle de acesso, mas nem toda falha de controle de acesso é um IDOR.
Por que o controle de acesso quebrado é o número um do OWASP Top 10?
A OWASP o classifica em primeiro porque seus dados mostraram alguma forma de fraqueza de controle de acesso em uma parcela maior de aplicações testadas do que qualquer outra categoria, e o impacto é alto. Uma única verificação de autorização ausente pode expor todos os registros de uma tabela ou conceder controle administrativo completo, e essas verificações estão espalhadas por tantos endpoints que uma quase sempre é esquecida.
Como se previne o controle de acesso quebrado?
Imponha a autorização no servidor para cada requisição, negue o acesso por padrão e baseie cada decisão na sessão autenticada em vez de em valores que o cliente envia. Verifique se o usuário logado possui o objeto específico antes de devolvê-lo, centralize a lógica em uma única camada e nunca conte com links ocultos ou botões desabilitados, que o cliente pode contornar.
Os UUIDs previnem o IDOR?
Não. Substituir identificadores sequenciais por UUIDs aleatórios torna as referências mais difíceis de adivinhar, o que retarda a enumeração, mas não é uma verificação de autorização. Se um UUID vazar por um link, uma exportação ou um cabeçalho referer e o servidor ainda não verificar a propriedade, o IDOR continua explorável. UUIDs são um quebra-molas, não um controle.
Parte da série OWASP Top 10
Artigos relacionados:
- Tutorial de Injeção SQL
- XSS vs CSRF
- O ataque SSRF explicado
- O controle de acesso quebrado explicado
- Guia de Teste de Segurança Web OWASP
Seus próximos passos
O controle de acesso quebrado fica claro no momento em que você explora um: mude um único número, veja carregarem os dados de um desconhecido, e a razão de ele liderar o OWASP Top 10 deixa de ser abstrata. Ler que a autorização deveria ser verificada no servidor é uma coisa, ver uma aplicação esquecer de fazê-lo e lhe entregar o painel de administração é outra. Comece pelo plano gratuito da HackerDNA, sem cartão de crédito, e alcance arquivos que nunca foram feitos para você no lab IDOR Explorer. Quando quiser o controle de acesso no contexto de toda a superfície de ataque, o curso Web Attacks o percorre ao lado da injeção SQL, do XSS e do resto do OWASP Top 10 em labs guiados no navegador. Aprenda a identificar a verificação ausente, depois vá escrever a que a detém.
