API Security10 min de leitura• Publicado em 2026-09-03

OWASP API1: Broken Object Level Authorization (BOLA / IDOR)

#api-security#bola#idor#owasp-top-10#authorization

Broken Object Level Authorization (BOLA), historicamente conhecido como Insecure Direct Object Reference (IDOR), lidera o ranking do OWASP API Security Top 10 por uma razão clara: é frequente, simples de explorar e tem impacto devastador. Ocorre quando uma API expõe um endpoint que manipula um recurso por seu identificador sem validar se o usuário autenticado tem direito legítimo de operar aquele objeto específico.

§1. Autenticação vs. Autorização: A Raiz do Problema

A grande armadilha para times de desenvolvimento é acreditar que exigir um Bearer Token ou cookie de sessão válido no cabeçalho é suficiente para garantir segurança. A autenticação valida apenas 'quem você é', enquanto a autorização define 'o que você pode fazer e sobre quais dados'.

A API valida a assinatura do token JWT com sucesso.
A query de busca no banco consulta o registro utilizando apenas o ID passado na rota: SELECT * FROM orders WHERE id = :id.
Como o token pertencia ao Usuário A, mas o ID pertencia ao Usuário B, a informação vaza sem disparar erro 403/401.

§2. Padrões de Endpoints e Vetores de Ataque

BOLA não se limita apenas a parâmetros na URL através do método GET. Ele se manifesta em operações destrutivas e alterações cadastrais em massa.

terminal / payload

http

### Cenário 1: Leitura Indevida via Parâmetro de Rota
GET /api/v1/invoices/10442 HTTP/1.1
Host: api.empresa.com
Authorization: Bearer <TOKEN_VALIDO_DO_USUARIO_A>
--> Retorna a fatura privada do Usuário B

### Cenário 2: BOLA em Operação Destrutiva (DELETE)
DELETE /api/v1/workspaces/88/members/501 HTTP/1.1
Host: api.empresa.com
Authorization: Bearer <TOKEN_MEMBRO_COMUM>
--> Remove membro de outro workspace sem checar hierarquia

### Cenário 3: Manipulação de ID no Corpo JSON (POST / PUT)
POST /api/v2/wire-transfer HTTP/1.1
Host: api.bank.com
Authorization: Bearer <TOKEN_VALIDO>
Content-Type: application/json

{
  "origin_account_id": "98124",  // ID manipulado para outra conta
  "dest_account_id": "12345",
  "amount": 500.00
}

Ao auditar APIs, altere métodos HTTP (ex: de GET para PUT ou DELETE) e tente repassar IDs em cabeçalhos alternativos como X-User-Id ou X-Original-User.

§3. Automação de Testes com ffuf e Burp Suite

Para identificar falhas BOLA em larga escala, analistas ofensivos utilizam automação com listas sequenciais ou dicionários de IDs mapeados:

terminal / payload

bash

# Testando enumeração massiva de pedidos com ffuf e token autenticado:
ffuf -u https://api.alvo.com/api/v1/orders/FUZZ \
     -w <(seq 1000 2000) \
     -H "Authorization: Bearer SEU_JWT_TOKEN" \
     -mc 200 \
     -fs 45 \
     -o bola_scan.json

Prevenção e Mitigação Recomendada

✓Implementar controle de autorização baseado em contexto no nível do serviço/repositório de dados.
✓Em vez de buscar por ID isolado, associar sempre à identidade do token: SELECT * FROM documents WHERE id = :doc_id AND user_id = :auth_user_id.
✓Substituir IDs sequenciais previsíveis (autoincrement) por UUIDs versão 4 (aleatórios e criptograficamente seguros).
✓Adotar políticas granulares de ABAC (Attribute-Based Access Control) ou RBAC em middlewares de rota.