Como saber se sua API está exposta: checklist de BOLA e BFLA

A maioria dos vazamentos de dados via API não acontece por uma falha exótica. Acontece porque a aplicação autentica quem você é, mas não verifica o que você pode acessar. É a diferença entre conferir o crachá na portaria e deixar a pessoa abrir qualquer porta do prédio.

Essas falhas têm nome no OWASP API Security Top 10: BOLA e BFLA. Juntas, respondem pela maior fatia dos incidentes graves em APIs. A boa notícia é que são testáveis — e este checklist mostra como.

BOLA: acessando o objeto do outro

BOLA (Broken Object Level Authorization) é quando a API verifica que você está logado, mas não confere se aquele recurso específico é seu.

O teste é simples: troque o identificador na requisição.

GET /api/v1/invoices/1043     → sua fatura (esperado)
GET /api/v1/invoices/1044     → fatura de outro cliente (FALHA se retornar 200)

Onde procurar:

• IDs sequenciais ou previsíveis em rotas (/users/{id}, /orders/{id}).
• Identificadores no corpo de requisições POST/PUT.
• Parâmetros em filtros e exports (?account_id=).
• UUIDs ainda são vulneráveis se vazarem em respostas anteriores.

Pergunta de validação: trocando o ID por um que não pertence à minha conta, recebo 403/404? Se receber 200 com dados, você tem um BOLA.

BFLA: executando a ação que não deveria

BFLA (Broken Function Level Authorization) é sobre ações, não objetos. Um usuário comum conseguindo executar uma função administrativa.

O teste: pegue um endpoint de admin e chame com um token de usuário comum.

DELETE /api/v1/users/55              (usuário comum chamando rota de admin)
POST   /api/v1/admin/promote        (token sem privilégio)
PATCH  /api/v1/orders/88/refund     (papel sem permissão de estorno)

Onde procurar:

• Verbos HTTP não previstos (a UI só mostra GET, mas o PUT funciona?).
• Endpoints administrativos sem checagem de papel no backend.
• Funções que confiam no frontend para esconder o botão — mas não bloqueiam a chamada direta.

Checklist rápido de exposição

Antes de assumir que sua API está segura, responda:

• [ ] Toda rota que recebe um ID valida propriedade do recurso no backend?
• [ ] A autorização é checada por função/papel, não só por autenticação?
• [ ] A verificação está no servidor, nunca apenas escondida na UI?
• [ ] Endpoints administrativos exigem papel explícito?
• [ ] Verbos HTTP não usados pela UI estão bloqueados ou tratados?
• [ ] Logs registram tentativas negadas de acesso a objetos alheios?
• [ ] Há testes automatizados que rodam com tokens de papéis diferentes?

Cada "não" acima é uma porta. Algumas levam a um único registro. Outras, ao banco inteiro.

Por que isso passa despercebido

Scanners automáticos (DAST) detectam mal essas falhas, porque autorização é lógica de negócio — a ferramenta não sabe que a fatura 1044 não é sua. Por isso BOLA e BFLA exigem teste manual ou testes escritos com conhecimento do domínio.

É exatamente o tipo de falha que um pentest focado em API encontra e um scan de prateleira ignora.

Como a NexGuard pode ajudar

Na NexGuard, testes de autorização objeto a objeto fazem parte do nosso pentest de APIs — exploramos BOLA, BFLA e lógica de negócio com a profundidade que scanner nenhum alcança, usando tokens de papéis distintos e cenários reais do seu domínio.

Você recebe um relatório com cada falha reproduzível, a severidade e o caminho de correção — e retest gratuito para confirmar que a brecha foi fechada.

👉 Quer saber se sua API expõe dados sem perceber? Fale com a NexGuard e agende um diagnóstico focado em API Security.