BOLA: a vulnerabilidade de API que fica bem diante dos nossos olhos

Imagine entrar no aplicativo do seu banco e ver o saldo da conta, o histórico de transações e seus dados pessoais. Tudo funciona exatamente como esperado. Agora imagine mudar um único número na URL (o ID da conta) e, de repente, ver os dados financeiros de outra pessoa. Sem ferramentas de invasão. Sem uma cadeia de exploração sofisticada. Apenas um dígito.

Isso não é hipotético. Esse é exatamente o tipo de vulnerabilidade que levou a exposição dos dados de 37 milhões de clientes da T-Mobile em uma violação divulgada em 2023, que acabou resultando em um acordo de US$ 350 milhões em uma ação coletiva.

É o mesmo tipo de falha que permitiu a invasores acessar dados pessoais e estatísticas de treino de qualquer usuário da Peloton simplesmente trocando IDs de usuário em solicitações de API. E é o mesmo padrão de vulnerabilidade que, no Harbor (um registro de contêineres amplamente utilizado), permitiu que um usuário com uma função básica de manutenção tornasse público um projeto privado inteiro e implantasse imagens não verificadas, manipulando metadados do projeto por meio de uma chamada de API não autorizada.

A vulnerabilidade por trás de todos esses incidentes tem um nome: Broken Object Level Authorization (BOLA). Ela ocupa a 1ª posição no OWASP API Security Top 10 e é, provavelmente, a falha mais comum, perigosa e subestimada na segurança de APIs modernas.

O que é BOLA?

Broken Object Level Authorization é uma falha de autorização em que uma API ou aplicação web não verifica se o usuário que faz uma solicitação tem permissão legítima para acessar ou modificar o objeto de dados específico que está tentando alcançar. Quando um usuário solicita um recurso, como um registro de banco de dados, um arquivo ou uma transação, a aplicação deve verificar não apenas se o usuário está autenticado (ou seja, se é quem diz ser), mas também se está autorizado a interagir com aquele objeto específico (ou seja, se tem o direito de vê-lo ou alterá-lo).

Quando essa verificação de autorização não existe, é fraca ou é aplicada de forma inconsistente, um invasor pode acessar os dados de outros usuários simplesmente manipulando o identificador do objeto na solicitação. Altere o número da conta em um parâmetro da URL. Troque um ID de usuário no cabeçalho de uma API. Modifique o ID de um recurso em um payload JSON. Se o servidor não validar a titularidade do objeto em cada solicitação, ele entregará dados que deveria proteger.

Vale a pena diferenciar isso de autenticação. A autenticação responde à pergunta "quem é você?", verificando a identidade por meio de credenciais, tokens ou mecanismos de autenticação multifator. A autorização responde à pergunta "o que você tem permissão para fazer?", determinando quais recursos e ações são permitidos para aquela identidade. A BOLA explora uma falha na segunda verificação. O usuário está autenticado, conectado e verificado. Ele simplesmente está acessando objetos que não lhe pertencem, e a aplicação não faz nada para impedir isso.

BOLA e IDOR: a mesma falha, sob perspectivas diferentes

Se você trabalha com segurança de aplicações há algum tempo, vai reconhecer que o que a OWASP chama de BOLA se parece muito com outra vulnerabilidade bastante conhecida: Insecure Direct Object References (IDOR). Esse é um tema que realmente gera controvérsia na comunidade de cibersegurança, e a sobreposição entre os nomes causa confusão que vale a pena esclarecer.

A IDOR tem origem no OWASP Web Application Security Top 10, onde apareceu já em 2007. O termo descreve um padrão específico de ataque: uma aplicação expõe uma referência direta a um objeto interno, como uma chave de banco de dados, um nome de arquivo ou um ID sequencial, e um invasor manipula essa referência para acessar algo que não deveria. A IDOR se concentrava principalmente no mecanismo de exploração: o identificador previsível, fácil de adivinhar ou enumerar que o invasor altera.

Introduzida no OWASP API Security Top 10 em 2019, a BOLA descreve a mesma falha fundamental, mas sob uma perspectiva mais ampla. Enquanto a IDOR se concentrava na referência manipulável, a BOLA reformula o problema como aquilo que ele realmente é: uma falha de autorização no nível do objeto.

A ênfase muda do vetor de ataque ("a referência é insegura") para a causa raiz ("a autorização está quebrada"). A BOLA também reconhece explicitamente que essas falhas vão além da simples manipulação de URLs: elas podem ocorrer em corpos de solicitações de API, cabeçalhos, grafos de objetos aninhados e entre limites de microsserviços, onde a lógica de autorização pode ser implementada de forma inconsistente.

Na prática, os dois termos descrevem a mesma família de vulnerabilidades. Quer você chame de IDOR ou BOLA, o problema central é idêntico: a aplicação confia em identificadores fornecidos pelo usuário sem executar verificações adequadas de autorização no servidor para o objeto específico solicitado. As defesas são as mesmas. O impacto nos negócios também.

A diferença de nomenclatura importa, porém, por dois motivos:

• Primeiro, como forma de enquadrar o problema, BOLA é mais útil para arquiteturas modernas baseadas em APIs, pois coloca a conversa no campo da lógica de autorização, e não em um padrão técnico específico. Em um mundo de microsserviços, arquiteturas compostas e ecossistemas de APIs cada vez mais complexos, pensar na autorização de forma abrangente — em todos os endpoints e para cada objeto — é mais produtivo do que se preocupar se um parâmetro de URL pode ser adivinhado.

• Segundo, como a BOLA ocupa a 1ª posição no OWASP API Security Top 10 e a IDOR está incluída na categoria mais ampla "Broken Access Control" do OWASP Web Application Top 10, usar os dois termos corretamente demonstra que você entende toda a dimensão do problema em contextos web e de API.

No restante deste artigo, usaremos BOLA como termo principal, mas, sempre que você encontrar BOLA, saiba que a IDOR faz parte da mesma história.

Por que a BOLA é especialmente perigosa

A BOLA ocupa uma posição particularmente perigosa no cenário de vulnerabilidades porque reúne três características que raramente aparecem juntas: é fácil de explorar, difícil de detectar e tem um impacto devastador.

Fácil de explorar.

Ataques BOLA não exigem ferramentas sofisticadas, conhecimentos técnicos avançados ou cadeias de exploração complexas. Um invasor pode procurar essas vulnerabilidades usando apenas um navegador, uma ferramenta de proxy ou um script simples. Altere um parâmetro e observe a resposta. Se os dados retornados não deveriam estar disponíveis, a aplicação está vulnerável. A barreira de entrada é praticamente inexistente, o que significa que essas falhas podem ser exploradas por uma variedade muito maior de agentes de ameaça do que a maioria das outras classes de vulnerabilidade.

Difícil de testar. 

Os métodos tradicionais de teste de segurança têm dificuldade com BOLA porque essas falhas não são técnicas no sentido convencional; são erros de lógica. Uma injeção de SQL deixa um padrão detectável em uma consulta. Uma vulnerabilidade de Cross-Site Scripting (XSS) gera payloads reconhecíveis. Já a BOLA envolve uma solicitação de API perfeitamente bem formada e sintaticamente correta, que simplesmente retorna dados pertencentes ao usuário errado. Não há entrada malformada, payload suspeito ou padrão anômalo. A solicitação parece legítima. A resposta também. O único problema é que a pessoa que fez a solicitação não deveria ter recebido aquela resposta específica.

Capaz de contornar as defesas modernas. 

Mesmo organizações com uma postura de segurança madura — com firewalls de aplicações web, gateways de API, limitação de taxa e controles de autenticação — ainda podem estar vulneráveis à BOLA. Essas defesas foram projetadas para detectar acessos não autorizados, solicitações malformadas e padrões de ataque conhecidos. A BOLA opera inteiramente dentro dos limites do tráfego normal e autenticado. O usuário tem credenciais válidas. O formato da solicitação está correto. O gateway de API vê um usuário autenticado fazendo uma solicitação aparentemente legítima. Nada aciona um alerta.

As consequências para os negócios são proporcionais à gravidade: violações de dados que expõem milhões de registros, penalidades regulatórias, ações coletivas e danos à reputação que levam anos para serem reparados. Quando o ataque é tão simples quanto mudar um número em uma URL, a questão não é se os invasores vão tentar, mas se suas aplicações vão impedi-los.

O que causa a BOLA?

As vulnerabilidades BOLA raramente resultam de um único erro de engenharia. Elas tendem a surgir de um conjunto de suposições profundamente equivocadas sobre como as APIs são projetadas, desenvolvidas e mantidas.

Muitas vezes, desenvolvedores confiam demais nas verificações do lado do cliente e presumem que os usuários não vão adulterar IDs de objetos ou tokens. Essa suposição é fundamentalmente errada, como demonstram repetidamente os exemplos de violações citados acima. Além disso, a lógica de autorização costuma ser implementada de forma inconsistente entre endpoints. Sem uma estrutura centralizada de autorização — quando cada endpoint implementa suas próprias verificações de controle de acesso (ou se esquece delas) —, as lacunas são inevitáveis. Uma aplicação pode aplicar a autorização corretamente em 99 de 100 endpoints. O endpoint que ficou de fora se torna a porta de entrada.

As práticas de teste agravam o problema. Testes de segurança manuais e automações com baixa cobertura raramente detectam BOLA porque essas vulnerabilidades não se baseiam em padrões. Não é possível encontrá-las procurando assinaturas conhecidas. Detectar BOLA com eficácia exige entender a lógica de negócios, a titularidade dos dados e o contexto de cada solicitação — capacidades que, historicamente, estavam fora do alcance das ferramentas automatizadas.

E há também a realidade do desenvolvimento de software moderno: a velocidade vem em primeiro lugar. As equipes de desenvolvimento sofrem pressão constante para lançar APIs rapidamente e atender às demandas dos negócios, e a validação da autorização muitas vezes fica em segundo plano diante da entrega de funcionalidades. A vulnerabilidade BOLA que resulta dessa escolha pode passar despercebida por meses ou anos, até que um invasor a encontre.

O desafio da detecção

Identificar BOLA em escala é um dos maiores desafios da segurança de aplicações, e vale entender por quê.

O principal desafio é que detectar BOLA com eficácia exige compreensão contextual. O scanner precisa saber não apenas que uma API retorna dados, mas também se esses dados devem estar acessíveis ao usuário específico que fez a solicitação. Esse recurso é público ou privado? O usuário que fez a solicitação é o titular desse objeto? Um usuário com essa função deveria poder ver esse campo? Essas perguntas dependem inteiramente da lógica de negócios e das regras de autorização da aplicação. Não é possível respondê-las com correspondência de padrões ou detecção baseada em assinaturas.

Abordagens simples para detectar BOLA, como verificar se a alteração de um ID retorna dados diferentes, geram níveis inaceitáveis de falsos positivos. Muitas APIs disponibilizam intencionalmente recursos públicos que podem ser acessados por qualquer usuário autenticado. Um catálogo de produtos, um perfil público ou um documento compartilhado: todos devem ser acessíveis a vários usuários. Sinalizar todo caso em que duas pessoas conseguem acessar o mesmo recurso como um possível problema de BOLA gera tanto ruído que os achados reais se perdem. Equipes de AppSec, que já trabalham no limite da capacidade, não podem se dar ao luxo de investigar centenas de falsos positivos para encontrar algumas poucas falhas reais de autorização.

É por isso que alguns concorrentes que dizem oferecer detecção de BOLA apresentam resultados superficiais. Sem entender o contexto do que está sendo acessado e se esse acesso deveria ser restrito, os mecanismos de detecção continuam sendo ingênuos, e a relação entre sinal e ruído continua ruim.

Por que isso importa mais do que nunca

A urgência em detectar BOLA não é teórica. Várias forças convergentes estão tornando essa classe de vulnerabilidade mais comum e perigosa do que em qualquer outro momento.

1. A superfície de ataque das APIs está se expandindo. 

As aplicações modernas já não são bases de código monolíticas: elas são compostas por microsserviços que se comunicam por meio de APIs, e arquiteturas compostas estão substituindo os antigos monólitos de código. Cada novo microsserviço, endpoint de API e integração pode ser um ponto de exposição a BOLA. O número de endpoints de API em um ambiente empresarial típico cresceu várias ordens de magnitude, e a lógica de autorização precisa ser implementada corretamente em todos eles.

2. O código gerado por IA está acelerando o problema. 

Atualmente, 76% dos desenvolvedores usam ou planejam usar ferramentas de programação com IA (Stack Overflow, 2024), e um estudo com cinco grandes modelos de IA constatou que pelo menos 48% dos trechos de código gerados por eles continham vulnerabilidades. Quando o código é gerado na velocidade das máquinas, a superfície sujeita a erros de autorização aumenta na mesma proporção. Desenvolvedores que trabalham com assistentes de programação com IA estão entregando mais código e mais rápido, mas a lógica de autorização desse código é tão boa quanto os prompts e os processos de revisão envolvidos. Em muitos casos, o código gerado funciona, mas deixa de incluir verificações de autorização que um desenvolvedor atento à segurança teria implementado.

3. Agentes de IA estão criando novas vias de exposição. 

O crescimento dos agentes autônomos de IA, que interagem com dados e serviços internos por meio de APIs, acrescenta outra dimensão ao problema. Esses agentes se comunicam pelos mesmos endpoints de API que atendem usuários humanos, mas operam na velocidade das máquinas e podem encadear várias chamadas de API de maneiras que não correspondem aos padrões de uso humano. Se esses endpoints tiverem vulnerabilidades BOLA, um agente poderá ser transformado em arma — ou um invasor poderá explorar os mesmos endpoints usados pelo agente — para exfiltrar dados ou modificar recursos em grande escala.

Um agente que usa uma API comprometida por BOLA não é apenas uma vulnerabilidade: é uma máquina automática de exfiltração de dados.

Quatro dos cinco principais itens do OWASP API Security Top 10 são problemas de autorização e autenticação. BOLA não é um problema isolado: é o sintoma mais evidente de um desafio sistêmico na forma como as aplicações modernas controlam o acesso. Detectar BOLA abre caminho para resolver uma família mais ampla de falhas de autorização, responsável pela maioria dos riscos críticos de segurança de APIs.

Uma nova abordagem: detecção de BOLA com IA

O desafio de detecção que tornou BOLA tão persistente é, em essência, um problema de compreensão contextual. E é justamente nesse ponto que os avanços recentes em IA e grandes modelos de linguagem (LLMs) estão mudando o cenário.

A abordagem pioneira da Snyk API & Web usa LLMs para analisar o contexto das solicitações de API e da lógica de autorização. Ela vai além das técnicas tradicionais de DAST para classificar a propriedade do conteúdo e determinar se o usuário que fez a solicitação deveria ter acesso à resposta. Em vez de depender de heurísticas simples de troca de IDs, que geram falsos positivos, o mecanismo de detecção com IA consegue avaliar se os dados são públicos ou privados, se o usuário solicitante é o proprietário legítimo e se o limite de autorização foi realmente violado.

Isso não significa substituir os fundamentos do Teste Dinâmico de Segurança de Aplicações. O DAST continua sendo essencial: testa as aplicações de fora para dentro e investiga a superfície de ataque com payloads em grande escala, como um invasor faria. O que a IA acrescenta é uma camada de inteligência contextual a essa metodologia de teste, permitindo detectar vulnerabilidades invisíveis para abordagens baseadas em correspondência de padrões. O resultado é uma detecção de BOLA com uma redução drástica nos falsos positivos, para que as equipes de AppSec recebam descobertas acionáveis, prontas para serem tratadas, em vez de ruído que precisam filtrar.

E BOLA é só o começo. A mesma abordagem orientada por IA está sendo ampliada para detectar outras falhas de autorização e autenticação do OWASP API Security Top 10, pois o desafio técnico de compreender o contexto da lógica de negócios se aplica a toda a família de vulnerabilidades de controle de acesso. Detectar BOLA cria a base para uma abordagem muito mais inteligente aos testes de segurança de APIs.

O que as lideranças de segurança devem perguntar

Se você é responsável pelo programa de segurança de aplicações da sua organização, BOLA deve estar entre as prioridades da sua avaliação de riscos. Considere estas perguntas:

Você sabe como a autorização é implementada nos endpoints das suas APIs? E essa implementação é consistente? É na inconsistência que BOLA prospera. Uma estrutura centralizada de autorização, aplicada em todos os serviços, é a defesa arquitetural mais eficaz.

As ferramentas de teste que você usa hoje conseguem realmente detectar BOLA ou afirmam que conseguem, mas geram principalmente falsos positivos? Nem toda detecção de BOLA tem a mesma qualidade. Peça evidências de precisão: taxas de falsos positivos, metodologia de detecção e resultados em situações reais.

Como você está considerando as implicações de autorização do código gerado por IA? Se seus desenvolvedores usam assistentes de programação com IA, o código que entregam pode funcionar corretamente, mas ter lacunas de autorização. Sua metodologia de testes precisa detectar o que uma revisão de código talvez não perceba.

E, por fim: você está testando de fora para dentro? Por natureza, falhas de autorização como BOLA só ficam totalmente visíveis quando você testa a aplicação como um invasor faria: investigando APIs e aplicações web em execução com solicitações e payloads reais, sob a perspectiva de quem tenta acessar o que não deveria. A análise estática pode identificar possíveis problemas no código. Os testes dinâmicos comprovam se eles podem ser explorados de fato.

BOLA ocupa o primeiro lugar no OWASP API Security Top 10 por um motivo. É uma vulnerabilidade disseminada, difícil de encontrar e que, quando explorada, pode custar milhões de dólares e expor milhões de registros. A boa notícia é que o desafio de detecção já pode ser superado: abordagens com IA permitem encontrar essas falhas com a precisão e a compreensão contextual que as ferramentas tradicionais nunca conseguiram oferecer. A questão é: sua organização vai encontrá-las antes de um invasor?