BOLA, BOPLA e BFLA: as 3 falhas que dominam APIs em 2026

O OWASP API Top 10 começa com BOLA, BFLA e BOPLA — três classes de falha de autorização que dominam a lista desde 2019 e seguem dominando em 2026. Não é coincidência. São as 3 classes que mais aparecem em programas de bug bounty internacionais, que mais derrubam SaaS B2B em produção, e que nenhum scanner detecta direito.

Este artigo explica cada uma em profundidade, mostra como pesquisador real ataca, e o que time de produto precisa fazer para bloquear.

O contexto: API Top 10 versão 2023

Em 2023 o OWASP atualizou a API Top 10. As 3 primeiras posições são, em ordem:

4 das 5 primeiras são falhas de autorização. API security em 2026 é, antes de qualquer outra coisa, autorização correta.

BOLA — Broken Object Level Authorization

O que é

Conhecida historicamente como IDOR (Insecure Direct Object Reference). Acontece quando um endpoint API recebe um ID e devolve o objeto correspondente sem verificar se o usuário autenticado tem permissão para acessar aquele objeto específico.

Exemplo clássico

Endpoint: GET /api/orders/12345

Vítima legitimamente acessa o pedido 12345. Atacante muda para 12346, 12347, e vê pedidos de outros usuários. Em SaaS B2B, isso é catastrófico — viola contrato, viola LGPD, mata renovação.

Variações modernas (que scanner não pega)

• UUID guessing— “UUID é seguro”, dizem. Não é. UUIDs são frequentemente vazados em logs, em emails, em headers, em URLs compartilhadas. Atacante coleta UUIDs por OSINT e tenta cada um.
• Indireto via parâmetro secundário — endpoint GET /api/me/ordersparece seguro porque usa “me”. Mas se o backend lêX-User-Id do header, atacante muda esse header e pega pedidos de outros.
• Search-based BOLA — endpoint de busca devolve lista. Filtro?owner=<id> não tem ACL. Atacante busca por owner=outro-tenant e vê tudo.
• BOLA em ações destrutivas — DELETE /api/users/123 sem checar se o user 123 pertence ao tenant do solicitante. Atacante deleta usuários de outros tenants.

Por que scanner não detecta

Scanner não tem contexto de quem deveria ter acesso a quê. Ele vê o endpoint respondendo 200, devolvendo JSON, e marca como OK. Detectar BOLA exige criar dois usuários em contextos diferentes e tentar cruzar — trabalho manual.

Como bloquear

• Cada endpoint deve verificar autorização no nível do objeto, não apenas autenticação
• Padrão: extrair tenant_id da sessão JWT, comparar com tenant_id do objeto requisitado
• Centralizar lógica de autorização em middleware ou policy engine (Casbin, OPA, Cedar)
• Testes automatizados: para cada endpoint, criar 2 usuários e tentar cross-access

BFLA — Broken Function Level Authorization

O que é

Acontece quando um usuário sem o papel adequado consegue executar uma função que deveria ser restrita a outros papéis. Geralmente afeta endpoints administrativos.

Exemplo clássico

Endpoint DELETE /api/admin/users/123 deveria ser acessível só para admins. Mas o frontend só esconde o botão para usuários comuns — o backend não valida o papel. Usuário comum chama o endpoint via curl e deleta usuários.

Variações modernas

• HTTP method confusion — endpoint POST /api/users/{id}válido para edição própria, mas PUT ou PATCH no mesmo path é aceito sem validação adicional, e PATCH permite mais campos
• Headers de override — X-HTTP-Method-Override: DELETE em POST request engana middleware mal configurado
• Endpoints “paralelos” — /api/v2/users/{id}tem ACL nova, /api/v1/users/{id} ainda existe e não tem
• Endpoints administrativos sem prefixo — /api/users/promotesem prefixo “admin” passa despercebido em revisão de código

Como bloquear

• Default deny: nenhum endpoint é público até ser explicitamente autorizado
• RBAC ou ABAC implementado em middleware, não em handler individual
• Logs estruturados de toda autorização negada (para detecção)
• Testes de matriz: para cada endpoint × cada papel, validar comportamento esperado

BOPLA — Broken Object Property Level Authorization

O que é

BOPLA é a evolução de mass assignment + excessive data exposure. Acontece em dois sabores:

1. Excessive data exposure: endpoint devolve mais propriedades do objeto do que o usuário deveria ver. Frontend filtra na exibição, mas API devolve tudo.
2. Mass assignment: endpoint aceita mais propriedades para escrita do que o usuário deveria poder modificar.

Exemplo clássico — excessive data exposure

GET /api/users/123 devolve { name, email, role, salary, ssn }. Frontend só mostra name e email. Mas qualquer usuário com browser DevTools vê o objeto completo.

Exemplo clássico — mass assignment

PATCH /api/users/me aceita corpo JSON e faz spread em user.update(req.body). Usuário envia { "role": "admin", "tenant_id": "outro" }. Backend salva. Escalation imediata.

Variações modernas

• Nested mass assignment — PATCH /api/posts/123 aceita author.role; o ORM atualiza não só o post mas o autor também
• GraphQL field spreading — query devolve mais campos do que o resolver imagina; frontend testou só os campos pedidos, mas o atacante pede todos
• Update via include— APIs JSON:API style permitem “include” relacionamentos; updates podem cascatear
• Whitelist drift — desenvolveu lista permitida em janeiro, novos campos foram adicionados ao modelo em fevereiro e ninguém atualizou a whitelist

Como bloquear

• Definir DTOs (Data Transfer Objects) explícitos para input e output, separados do modelo de domínio
• Whitelist de propriedades atualizáveis (allow-list, nunca block-list)
• Em GraphQL: usar @auth directives no schema, permission por campo
• Para output, projeção explícita (SELECT específico, não SELECT *)
• Code review obrigatório quando modelo de domínio muda

O ataque combinado: chain BOLA + BOPLA

O exploit mais devastador combina BOLA e BOPLA:

1. BOLA permite atacante listar IDs de outros tenants (ex: GET /api/users?search=*)
2. BOPLA permite atacante editar campo sensível de outro tenant (ex: PATCH /api/users/<outro_tenant_user> com email alterado para o do atacante)
3. Atacante usa “forgot password” — recebe link de reset no email dele
4. Account takeover total, em qualquer conta da plataforma

Esse padrão apareceu em achados de bug bounty públicos em 2023–2024 valendo entre US$ 5.000 e US$ 25.000 por finding. Em SaaS B2B brasileiro, é o tipo de bug que termina contrato com cliente enterprise da noite para o dia.

Como o pentest sério ataca

Cobertura adequada exige:

• Auth Matrix — mapeamento sistemático de endpoints × papéis × verbos. Ferramenta proprietária (No Vuln) automatiza para 200+ endpoints
• 2 contas em tenants diferentes — pré-requisito básico. Sem isso, não dá para testar cross-tenant
• Diff de responses — entre roles diferentes, ver quais campos só aparecem para admin
• Mass Assign Tester — fuzzing de propriedades em PATCH/PUT
• IDOR Wildcard Probe — rotação de IDs com diferentes formatos (numérico, UUID, slug, base62)
• Revisão manual final, porque toda automação tem falsos negativos

Conclusão

BOLA, BFLA e BOPLA não são bugs raros. São os 3 bugs mais comuns em APIs de produção em 2026. E são invisíveis para scanners. Se o pentest da sua API não menciona explicitamente cobertura dessas 3 classes, com matriz de teste de papéis × endpoints, está incompleto — independente do preço.

Cobertura correta é trabalho manual qualificado. É exatamente o tipo de teste que diferencia “pentest com PDF bonito” de “pentest que de fato te protege”.