Questão de Segurança da Informação — Autorização e Controle de Acesso (RBAC, ABAC, MAC, DAC e ACL) — FCC 2026

Broken Object Level Authorization (BOLA) em APIs REST

Gabarito: letra D. O cenário descreve uma falha de Broken Object Level Authorization (BOLA) — a API autentica o usuário, mas não verifica se ele tem permissão para acessar o objeto específico identificado por {documentId}. A OWASP API Security Top 10 (2023) classifica essa vulnerabilidade como API1:2023 – Broken Object Level Authorization, que ocorre quando o backend confia apenas na autenticação e não valida a propriedade do recurso.

O problema central aqui é a distinção entre autenticação e autorização. Autenticação é o processo de verificar quem o usuário é (identidade); autorização é o processo de verificar o que esse usuário pode fazer (permissões). No cenário, o usuário está autenticado (Bearer token), mas o sistema não realiza a autorização no nível do objeto — ou seja, não confere se aquele documento pertence ao gabinete do usuário logado. Isso permite que um usuário acesse documentos de outros gabinetes simplesmente alterando o documentId na URL, caracterizando uma escalada de privilégios horizontal (usuário comum acessa dados de outro usuário da mesma categoria).

A OWASP define BOLA como a vulnerabilidade que ocorre quando uma API não verifica se o objeto pertencente ao identificador enviado na requisição pertence ao usuário autenticado. O exemplo clássico é uma API bancária onde o usuário pode consultar transações alterando o ID na URL, sem validação de propriedade. As consequências incluem violação de confidencialidade, violação de conformidade (LGPD, GDPR, PCI-DSS) e perda de confiança.

A prevenção adequada envolve implementar um mecanismo de autorização que verifique, em cada requisição, se o usuário autenticado tem permissão para acessar o objeto solicitado. Isso pode ser feito comparando o ID do usuário no JWT com o proprietário do recurso, ou usando políticas de acesso baseadas em papéis (RBAC) ou atributos (ABAC). A OWASP também recomenda preferir IDs aleatórios e imprevisíveis (como UUIDs) como medida complementar, mas isso não substitui a validação de autorização — apenas dificulta a descoberta de outros IDs.

A pegadinha desta questão está em confundir BOLA com Broken Function Level Authorization (BFLA). Enquanto BOLA protege o acesso ao objeto como um todo (API1), BFLA protege o acesso à funcionalidade/ação em si (API5). No cenário, o usuário acessa um documento (objeto) que não deveria — isso é BOLA. BFLA seria se o usuário conseguisse executar uma função administrativa (como deletar ou aprovar) sem ter permissão para tal.

Alternativa A — ❌ Incorreta

Afirma que a vulnerabilidade poderia ser completamente mitigada apenas substituindo IDs sequenciais por UUIDs aleatórios. Isso é falso: UUIDs dificultam a descoberta de outros IDs, mas não impedem o acesso se o backend não validar a autorização. Um usuário que conhece o UUID de outro documento (por exemplo, via referência em outro lugar) ainda conseguiria acessá-lo. A OWASP recomenda UUIDs como medida complementar, não como solução única. A mitigação correta exige validação de autorização no backend.

Alternativa B — ❌ Incorreta

Afirma que a vulnerabilidade poderia ser prevenida somente pela comparação entre o ID do usuário no JWT e o documentId. Essa é uma medida válida de prevenção, mas a alternativa usa o termo "somente", tornando-a incorreta — existem outras formas de mitigação (RBAC, ABAC, políticas de acesso). Além disso, a comparação direta entre ID do usuário e documentId nem sempre é aplicável: em muitos casos, o documento pertence a um gabinete (grupo), não a um usuário individual. A validação correta deve verificar se o usuário pertence ao gabinete dono do documento.

Alternativa C — ❌ Incorreta

Classifica a vulnerabilidade como de autenticação, afirmando que o JWT não impede o acesso a recursos de outros usuários. Isso confunde autenticação com autorização. O JWT cumpre seu papel de autenticar o usuário; o problema é a falta de autorização no nível do objeto. A vulnerabilidade é de autorização (BOLA), não de autenticação. A alternativa C descreve corretamente o sintoma (JWT não impede acesso a recursos de outros), mas erra ao classificá-lo como falha de autenticação.

Alternativa D — ✅ Correta ⟵ GABARITO

Identifica corretamente a vulnerabilidade como Broken Object Level Authorization (BOLA), pois o sistema não valida se o usuário autenticado tem permissão para acessar o objeto identificado por {documentId}. Isso corresponde exatamente à definição da OWASP API1:2023: a API autentica o usuário, mas não verifica a propriedade do recurso. O usuário consegue acessar documentos de outros gabinetes alterando o ID na URL, sem validação adicional no backend.

Alternativa E — ❌ Incorreta

Classifica a vulnerabilidade como Broken Function Level Authorization (BFLA), afirmando que o endpoint não restringe quais funções podem ser executadas. Isso é incorreto: BFLA ocorre quando o usuário executa funções/ações que não deveria (como deletar, aprovar, configurar). No cenário, o usuário acessa um objeto (documento) que não deveria — isso é BOLA, não BFLA. A distinção é clara: BOLA protege o acesso ao objeto; BFLA protege o acesso à funcionalidade.

Gabarito: letra D — a vulnerabilidade é Broken Object Level Authorization (BOLA), pois o sistema não valida se o usuário autenticado tem permissão para acessar o objeto identificado por {documentId}.