Quando se trata de falhas de autorização em nível de objeto (BOLA) — uma das 10 principais vulnerabilidades de segurança de APIs da OWASP —, a abordagem shift left é uma estratégia incompleta. BOLA não é um simples erro de programação, como um erro de digitação; é uma falha fundamental na lógica de negócios.
Confiar que os desenvolvedores verifiquem manualmente cada regra de propriedade em um amplo ambiente de microsserviços é uma aposta de alto risco. Em 2026, com as rigorosas regras de divulgação da Comissão de Valores Mobiliários dos Estados Unidos (SEC) e a aplicação incisiva do Regulamento Geral sobre a Proteção de Dados (GDPR), um “erro de lógica” pode rapidamente se transformar em um desastre financeiro significativo.
A anatomia da lacuna de autorização
Na era monolítica, a autorização era implícita. O servidor mantinha a sessão em sua própria memória, sabia exatamente quem estava conectado e controlava a consulta ao banco de dados em um único processo centralizado.
As arquiteturas modernas de nuvem romperam com esse modelo. Hoje, separamos a identidade (gerenciada por provedores externos) dos dados (distribuídos por centenas de serviços distintos). Verificamos quem é o usuário logo na entrada, mas muitas vezes deixamos para o desenvolvedor de backend a tarefa de verificar o que ele possui ou pode acessar.
“Em 2026, os ataques BOLA estão entre as formas mais rápidas de sofrer uma violação de dados. A abordagem shift left é boa para encontrar falhas técnicas, mas “permanecer à direita” é a única maneira de corrigir falhas na lógica de negócios.”
A “lacuna de autorização” é o espaço entre um login bem-sucedido e a ausência de uma verificação de propriedade. Como os serviços modernos não mantêm estado, eles confiam inerentemente nas solicitações que recebem. Se uma solicitação incluir “Pedido 7788” e o código não verificar explicitamente se o pedido pertence ao solicitante, os dados serão roubados.
Visualizando a lacuna de autorização
Para entender por que confiar apenas em um firewall de aplicações web (WAF) é insuficiente para se proteger contra vulnerabilidades BOLA, precisamos analisar a desconexão técnica entre a autenticação e a propriedade dos recursos em APIs modernas e sem estado. Os WAFs procuram sintaxes “maliciosas”, como injeção de SQL, mas os ataques BOLA usam sintaxes “válidas” que parecem fazer parte de uma solicitação normal. Para impedir ataques BOLA, sua defesa precisa levar a identidade em consideração, validando o usuário em relação ao objeto específico que ele está solicitando.
Considere um aplicativo bancário. Um invasor, o Usuário A, entra na própria conta (ID do usuário: 8899) e recebe um token de sessão válido. Esse usuário agora está autenticado, e o invasor pode tentar acessar os dados de outra pessoa, o Usuário B, enviando uma solicitação para /api/v1/accounts/1234/balance.
O WAF verifica se há injeção de SQL ou scripts maliciosos. Como 1234 é um número inteiro perfeitamente válido e a sintaxe está correta, o WAF permite que a solicitação prossiga.
O gateway de API verifica se o token de sessão é válido e se ainda não expirou. Como o Usuário A, o invasor, é um usuário legítimo e autenticado, o gateway marca a solicitação como autenticada e a encaminha aos sistemas internos no backend.
Como resultado, o serviço de backend recebe a solicitação “confiável” e retorna o saldo da conta 1234. O invasor conseguiu contornar a segurança porque o gateway confirmou quem ele era, mas nunca verificou o que ele tinha permissão para acessar.
Em muitas arquiteturas modernas, o gateway de API atua como um “segurança” que apenas verifica as credenciais na entrada. Depois que um usuário fornece um JWT ou cookie de sessão válido, o gateway presume que todas as solicitações subsequentes desse usuário são legítimas.
O usuário A faz login e recebe um token válido. Em seguida, envia uma solicitação para GET/api/v1/data/1234. A próxima etapa desse processo é a verificação da sintaxe e da sessão, na qual o WAF padrão confirma que a solicitação está livre de ameaças (sem injeção de SQL) e o gateway de API confirma que a sessão é válida.
É aqui que ocorre a falha de autenticação: nem o WAF nem o gateway verificam se o recurso 1234 realmente pertence ao Usuário A, e o serviço de backend confia cegamente na solicitação “verificada” pelo gateway e fornece os dados privados do Usuário B ao Usuário A. É nesse ponto que ocorre a violação.
No entanto, com uma solução avançada de segurança de APIs, esse novo segurança não apenas verifica a identidade do usuário na entrada, mas também confirma se ele tem autorização para entrar em cada sala específica que tenta acessar.
Veja as etapas que as soluções avançadas de segurança de APIs seguem para eliminar a lacuna de autenticação e validar se o usuário conectado tem permissão para executar a ação solicitada no objeto solicitado.
Na primeira etapa, o sistema extrai a identidade (Usuário A) do token e o ID do recurso (1234) da solicitação. Em seguida, usando um Mapa de Lógica de Negócios aprendido, a plataforma identifica que o recurso 1234 pertence ao Usuário B, e não ao Usuário A.
Na terceira etapa, como o mapeamento entre a identidade e o recurso não passa na verificação lógica, a solicitação é bloqueada na borda da aplicação, antes que possa interagir com os sistemas internos. Assim, a solicitação não autorizada nunca chega ao backend da aplicação, onde os dados são armazenados, impedindo a exfiltração de dados antes mesmo que ela comece.
Por que o shift left não consegue impedir o BOLA
Antecipar as verificações e os testes de segurança para estágios anteriores do ciclo de vida de desenvolvimento não é suficiente para resolver esse problema, pois as táticas de shift left não têm contexto. Ferramentas como a análise estática (SAST) examinam o código, não os dados, portanto não sabem que o Usuário A não está autorizado a ver a fatura do Usuário B, pois essa relação é definida no banco de dados, e não no código-fonte.
Além disso, a maioria das ferramentas de análise dinâmica (DAST) realiza verificações apenas no contexto de um único usuário. Elas recebem uma resposta “200 OK” e consideram o teste aprovado, sem perceber que o usuário está acessando os registros privados de outro usuário.
Por outro lado, os testes de API convencionais não levam o contexto em consideração. Em essência, é como testar no vácuo. Essa abordagem falha porque ignora os dados de tráfego do mundo real. Se os seus testes não conseguem identificar como a Identidade A está associada ao Recurso B em produção, eles só podem validar a sintaxe, não a lógica. Você não está testando o seu negócio.
Aplicação de políticas na borda
Para resolver esse problema, as organizações precisam de uma estratégia de runtime em três camadas, composta por:
- Mapeamento de usuário para recurso. A solução de segurança de APIs extrai a identidade do token e a compara com o ID do recurso na mensagem de solicitação HTTP (cabeçalho, cookie, caminho ou corpo).
- Um sidecar do Open Policy Agent (OPA). Em vez de confiar que centenas de desenvolvedores criem verificações específicas, use o OPA para gerenciar as regras de autorização em um único local centralizado. Um sidecar do OPA é um padrão de implantação executado junto a um contêiner de aplicação para fornecer decisões locais de autorização com baixa latência e alto desempenho, permitindo que as políticas sejam avaliadas em tempo real para microsserviços e segurança de APIs.
- Monitoramento comportamental. Para impedir ataques BOLA, sua defesa deve extrair a identidade (quem), o contexto (como) e o recurso (o quê) do tráfego em tempo real para estabelecer uma linha de base de relações normais. Por exemplo, se um único usuário se desviar de uma linha de base estabelecida, como ao tentar acessar 50 IDs diferentes em um minuto, o sistema identificará essa anomalia. Esse é um sinal claro de um scraper, não de uma pessoa, e deve ser bloqueado imediatamente.
Como a F5 ajuda
F5 Distributed Cloud API Security oferece um caminho claro desde a ausência de visibilidade até a proteção obrigatória em tempo de execução. Como parte do F5 Distributed Cloud Services, oferece segurança unificada, combinando a entrega e a segurança de aplicações em uma única plataforma. Ao correlacionar informações de componentes como mitigação de ataques distribuídos de negação de serviço (DDoS), proteção contra bots, segurança de APIs e WAF, distingue uma solicitação isolada de um cliente de ataques coordenados e multivetoriais por meio da automação.
O recurso de descoberta de APIs do produto encontra automaticamente todas as APIs, incluindo as “APIs ocultas”, e analisa continuamente o tráfego de produção para compreender a lógica de negócios real da sua aplicação e mapear como os usuários interagem com objetos de dados específicos. Os testes sensíveis ao contexto usam esses insights para executar “testes de matriz” direcionados em ambientes de pré-produção, identificando pontos fracos nos mapeamentos entre identidades e objetos antes da implantação do código.
Distributed Cloud API Security também oferece detecção de ataques BOLA, identificando diversos cenários de BOLA ao correlacionar linhas de base comportamentais aprendidas com solicitações recebidas para detectar atividades suspeitas, o que pode orientar as proteções em tempo de execução.
Em 2026, os ataques BOLA estão entre as formas mais rápidas de sofrer uma violação de dados. A abordagem shift left é boa para encontrar falhas técnicas, mas “permanecer à direita” é a única maneira de corrigir falhas na lógica de negócios. Leve sua autorização para a borda e interrompa agora o vazamento de dados.
Saiba como a F5 pode ajudar as organizações a proteger suas APIs ou veja a solução em ação.
Sobre os autores
Publicações relacionadas no blog
IA agêntica em cibersegurança: promessas e riscos
Saiba por que o uso de IA agêntica na cibersegurança é essencial para combater ameaças impulsionadas por IA e por que os agentes também criam novos riscos para as empresas.
Como os clientes da F5 no setor financeiro lidam com a soberania digital sem desacelerar a inovação
Como é a soberania digital na prática? Dois projetos recentes da F5 com clientes mostram como diferentes empresas estão enfrentando esses desafios.
Soberania operacional: construindo resiliência em um mundo imprevisível
Para muitas organizações, a questão já não se resume apenas a controlar os dados. Trata-se de manter a capacidade de operar, adaptar-se e se recuperar à medida que as leis e as condições evoluem.
Segurança de IA com evidências: o que levaremos ao Gartner SRM
Antes de sua sessão no Gartner SRM, o vice-presidente sênior de Marketing de Produtos da F5 explica como a F5 ajuda as organizações a proteger a IA em três etapas práticas.
Gestão de riscos de IA: como as proteções podem ajudar a mitigá-los
O risco da IA é impulsionado por comportamentos probabilísticos e pela explicabilidade limitada, não apenas por falhas de segurança. Uma gestão eficaz exige controle operacional contínuo.
Lei de IA do Colorado (SB 205): o que as empresas precisam saber antes de 2026
A SB 205 do Colorado, a lei pioneira do estado sobre inteligência artificial, foi sancionada pelo governador Jared Polis em 17 de maio de 2024. O projeto de lei estabelece requisitos para que as empresas que utilizam IA implementem controles destinados a proteger os cidadãos do Colorado.