Questão de Segurança da Informação — OWASP — FCC 2025

OWASP Top 10: Broken Access Control e IDOR

Gabarito: letra C. O cenário descreve um caso clássico de quebra de controle de acesso (Broken Access Control), mais especificamente IDOR (Insecure Direct Object Reference) — o usuário manipula o identificador na URL (452 → 453 → 454) e acessa registros de terceiros sem autorização, porque o sistema não verifica se o usuário autenticado tem permissão para acessar aquele objeto específico. Essa é a categoria A01 do OWASP Top 10.

O OWASP Top 10 é uma publicação da fundação sem fins lucrativos Open Web Application Security Project (OWASP) que lista as vulnerabilidades mais críticas, comuns e perigosas em aplicações web. A versão de 2021 (que permanece a base de referência para 2024) organiza os riscos em dez categorias, e a quebra de controle de acesso ocupa a primeira posição. O controle de acesso é o mecanismo que impõe a política de autorização: ele garante que usuários autenticados não possam agir fora de suas permissões pretendidas. Quando essa verificação falha, o atacante consegue acessar, modificar ou destruir dados de outros usuários, ou executar funções além do seu papel.

O caso do enunciado é o exemplo canônico de IDOR, que é uma espécie do gênero Broken Access Control. A aplicação expõe uma referência direta a um objeto (o número do cadastro na URL) e não valida se o usuário logado é o dono daquele objeto. A pergunta-chave que separa o IDOR de outras falhas é: "o usuário X, que tem permissão para ver cadastros, tem permissão para ver especificamente o cadastro #453?". Se a resposta é não, mas o sistema entrega os dados, há IDOR. Isso é diferente de uma falha de autenticação (que ocorre antes, na identificação do usuário) e de uma falha de injeção (que envolve a manipulação de comandos/consultas).

A distinção entre as categorias do OWASP é o ponto central desta questão. Veja como cada alternativa tenta confundir o candidato:

A pegadinha da banca está em trocar as características de uma categoria por outra. A alternativa A atribui o problema a design inseguro, mas o design inseguro é uma falha estrutural de arquitetura, não a ausência de verificação de permissão em um objeto específico. A alternativa B fala em falhas criptográficas, mas o problema não é a transmissão sem proteção — é a falta de autorização. A alternativa D fala em injeção, mas não há manipulação de comandos ou consultas; há apenas a alteração de um identificador numérico. A alternativa E fala em configuração incorreta, mas o cenário não descreve permissões padrão ou ambiente de produção mal configurado.

Guarde a fronteira entre autenticação (quem é você?) e autorização (o que você pode fazer?): o IDOR é uma falha de autorização, pois o usuário já está autenticado, mas o sistema não valida se ele tem permissão para acessar aquele recurso específico. É exatamente nessa fronteira que as alternativas se dividem.

Alternativa A — ❌ Incorreta

A alternativa afirma que se trata de design inseguro, pois a modelagem de ameaças não previu a validação de permissões. O design inseguro (A04) é uma falha estrutural de arquitetura, que ocorre na fase de planejamento e não pode ser corrigida por uma implementação perfeita. No caso narrado, o problema não é a ausência de um controle na arquitetura, mas a falha na implementação da verificação de autorização — o sistema deveria validar se o usuário tem permissão para acessar o cadastro 453, e não o faz. A modelagem de ameaças poderia ter previsto o risco, mas a categoria correta para a vulnerabilidade descrita é a quebra de controle de acesso, não o design inseguro.

Alternativa B — ❌ Incorreta

A alternativa fala em falhas criptográficas, pois os dados na URL estariam sem proteção. Essa é uma confusão clássica: o problema não é a ausência de criptografia na transmissão, mas a ausência de verificação de autorização. Mesmo que a URL fosse transmitida de forma criptografada (via HTTPS, por exemplo), o atacante autenticado ainda poderia alterar o identificador e acessar os dados de terceiros, pois o servidor não valida a permissão. A criptografia protege os dados em trânsito contra interceptação, mas não resolve o problema de autorização.

Alternativa C — ✅ Correta ⟵ GABARITO

A alternativa está correta ao diagnosticar controle de acesso quebrado/IDOR. O cenário descreve exatamente o padrão IDOR: o usuário altera o identificador na URL (452 → 453 → 454) e o sistema retorna dados de outros cidadãos sem verificar se o usuário tem permissão para acessar aquele objeto específico. Isso é uma falha de autorização, que se enquadra na categoria A01 do OWASP Top 10 (Broken Access Control). A ausência de verificação robusta de permissões permite o acesso indevido a recursos de outros usuários.

Alternativa D — ❌ Incorreta

A alternativa fala em ataque de injeção, pois parâmetros maliciosos seriam introduzidos na URL para manipular o banco de dados. A injeção (A03) ocorre quando dados fornecidos pelo usuário não são validados e são usados em consultas dinâmicas ou comandos, como SQL Injection. No caso narrado, não há manipulação de comandos ou consultas — o atacante apenas altera um identificador numérico na URL, e o sistema retorna os dados diretamente. Não há injeção de código malicioso; há uma falha de autorização.

Alternativa E — ❌ Incorreta

A alternativa fala em configuração incorreta de segurança, pois o sistema teria permissões padrão e informações expostas. A configuração incorreta (A05) envolve falta de configuração adequada, uso de contas padrão, recursos desnecessários ativados, entre outros. No cenário descrito, não há menção a configurações padrão ou ambiente de produção mal configurado — o problema é a ausência de verificação de permissões no acesso a objetos específicos, o que caracteriza quebra de controle de acesso.

Gabarito: letra C — controle de acesso quebrado/IDOR, pois a ausência de verificação robusta permite que usuários acessem recursos de outros indevidamente.