03 de JULHO
Embora os mecanismos de autenticação tenham avançado, muitas APIs ainda apresentam vulnerabilidades relacionadas a falhas de autorização. Dentre elas, o Broken Object Level Authorization (BOLA) se sobressai tanto pela recorrência quanto pelo impacto.
Afinal... O que é BOLA?
Classificada como a vulnerabilidade número 1 da OWASP API Security Top 10 - API1:2023 - Broken Object Level Authorization (Autorização de Nível de Objeto Quebrada), essa vulnerabilidade possibilita que usuários autenticados acessem objetos de outros usuários por falta de verificações de autorização apropriadas.
Na prática, o BOLA é uma das principais razões para vazamentos de dados em aplicações, sendo encontrado em APIs REST, GraphQL, aplicativos móveis e arquiteturas baseadas em microserviços.
Considere o endpoint abaixo:
A aplicação retorna corretamente os pedidos do usuário 1.
Entretanto, se alterar o identificador de usuário para 2 e a API retornar os dados do usuário 2, temos uma vulnerabilidade BOLA.
Por que BOLA é tão comum?
Existem três fatores principais:
1. Confiança excessiva na autenticação
Muitos desenvolvedores assumem que um usuário autenticado pode acessar qualquer recurso retornado pela API.
Autenticação responde:
Quem é você?
Autorização responde:
Você pode acessar este recurso?
A ausência da segunda pergunta gera o BOLA.
2. Exposição de identificadores previsíveis
Exemplos:
/users/1001
/users/1002
/users/1003
ou
/orders/5001
/orders/5002
/orders/5003
Mesmo UUIDs não eliminam o problema:
/orders/3f2fd6c0-9f89-4f41-8a82-0d45f9e5a621
Se a autorização não existir, o UUID apenas dificulta a enumeração.
3. Crescimento das APIs
Aplicações modernas possuem dezenas ou centenas de endpoints. É comum que verificações de autorização sejam implementadas em alguns endpoints e esquecidas em outros.
Dependendo do contexto, uma vulnerabilidade BOLA pode resultar em:
- Vazamento massivo de dados
- Violação da LGPD
- Exposição de documentos internos
- Escalada horizontal de privilégios
- Escalada vertical de privilégios
- Comprometimento de múltiplos clientes em ambientes SaaS
Por esse motivo, vulnerabilidades BOLA frequentemente recebem classificações High ou Critical.
Como mitigar BOLA na prática?
A validação de autorização deve ocorrer obrigatoriamente no backend, e nunca depender apenas de dados vindos do cliente (como IDs na URL).
Exemplo Inseguro
No cenário abaixo, qualquer usuário autenticado que alterar o document_id na requisição conseguirá acessar documentos de terceiros.
O sistema confia cegamente que se o usuário está logado, ele pode ver qualquer documento existente.
Exemplo Seguro
A forma correta envolve amarrar a busca do objeto à identidade do usuário que está realizando a requisição. O sistema garante que o objeto pertence ao usuário logado.
Se não encontrar (ou não pertencer ao usuário), aborta com erro:
Broken Object Level Authorization ainda é uma das principais vulnerabilidades em APIs modernas. Sua exploração tende a ser simples, seu impacto costuma ser significativo e sua presença é bastante frequente em aplicações web, mobile e ambientes SaaS.
Durante avaliações de segurança, a análise sistemática de controles de autorização deve ser considerada prioridade máxima. Em muitos casos, uma simples alteração de identificadores é suficiente para revelar falhas críticas capazes de comprometer dados de usuários.
Para garantir a segurança dos dados da sua empresa, fale com a nossa equipe no WhatsApp: (54) 3027-0722.
