BOLA em fintech: 1 endpoint, R$ 200k de exposição (war story 2026)

Em pentest de fintech brasileira que executamos recentemente, encontramos um BOLA (Broken Object Level Authorization) em endpoint de cartão. Cliente A conseguia ver TODO o histórico de transações de cliente B trocando um único parâmetro na URL.

Estimativa de exposição se explorado por atacante real: vazamento de histórico transacional de toda a base ativa — milhões de transações, com mapping completo entre cartão, valor e merchant. Em termos de LGPD: dado pessoal financeiro de centenas de milhares de titulares. Multa potencial: até 2% do faturamento (R$ 50M cap por incidente).

Este post é a análise técnica anonimizada do que aconteceu — porque o padrão se repete em quase toda fintech brasileira que auditamos. Se você opera SaaS B2B, fintech, marketplace ou qualquer plataforma multi-tenant, é leitura obrigatória.

A descoberta

Cliente nos contratou para pentest greybox completo da plataforma. Recebemos credenciais de 2 contas teste — vamos chamá-las de Conta A e Conta B. Ambas eram contas corporativas legítimas, com cartões corporativos atribuídos.

No mapeamento inicial, identificamos endpoint que servia o histórico de transações de cartão:

GET /api/v2/cards/{card_id}/transactions
Authorization: Bearer <token_da_conta>

Comportamento esperado: cada conta vê transações apenas dos cartões dela.

Comportamento real: substituindo {card_id} por um UUID de cartão da Conta B, o servidor retornava o histórico completo — para a Conta A autenticada com seu próprio token.

O bug em detalhe

A implementação validava apenas:

1. ✅ Que o token Bearer era válido (qualquer usuário autenticado passava)
2. ✅ Que o card_id existia no banco
3. ❌ Que o card_id pertencia ao tenant do usuário autenticado

A 3ª validação — a essencial — simplesmente não existia. O endpoint confiava que se você sabe o UUID do cartão, você tem direito de ver o histórico.

Isso é BOLA (Broken Object Level Authorization) — a vulnerabilidade #1 do OWASP API Security Top 10. Não é bug obscuro. É um dos vetores mais explorados em ataque real a APIs em 2026. Veja análise técnica detalhada das 3 falhas que dominam APIs em BOLA, BOPLA e BFLA.

Por que esse bug aparece tanto

Três padrões arquiteturais predispõem ao bug:

Padrão 1: ORM que esconde a query

Quando o ORM facilita escrever uma query sem o filtro de tenant, em code review parece correto, mas em runtime abre BOLA. Por exemplo, em Python/Django:

• ❌ Card.objects.get(id=card_id) — sem filtro de tenant
• ✅ Card.objects.get(id=card_id, tenant_id=user.tenant_id) — com filtro

A linha errada parece “correta” em code review. Quem escreve está focado no ID do recurso, não no contexto de autorização. Em runtime, BOLA aberto.

Padrão 2: Autorização “via middleware” insuficiente

Muitas aplicações implementam middleware de autenticação (valida token) e acham que isso é autorização. Não é.

• Autenticação responde: quem é você?
• Autorização responde: o que você pode fazer?

Sem middleware que valide ownership do recurso, autorização vira responsabilidade do dev em cada endpoint — e em algum momento alguém esquece.

Padrão 3: UUIDs dão falsa sensação de segurança

Devs frequentemente racionalizam: “O UUID tem 128 bits. Atacante não vai adivinhar.”

Verdade — atacante não adivinha. Mas atacante:

• Consegue UUIDs em respostas legítimas (listagens, webhooks emitidos, logs)
• Vaza UUIDs em URLs compartilhadas
• Coleta UUIDs em integrações third-party
• Consegue UUIDs via outros bugs (info disclosure, IDOR em outros endpoints)

Obscurity ≠ security. UUID não substitui autorização.

Como pesquisador encontra

Em pentest sério, BOLA é o primeiro lugar onde olhamos. O processo:

1. Cria 2 contas em tenants diferentes (essencial — não dá pra fazer com 1 conta)
2. Mapeia exaustivamente todos endpoints que recebem ID/UUID na URL ou body
3. Para cada endpoint, troca o ID por um pertencente ao outro tenant
4. Observa a resposta — 200 OK com dados = BOLA confirmado
5. Documenta com PoC reproduzível — request exato, response exato, severidade calibrada

Scanner automatizado NÃO faz isso. Não tem múltiplas sessões, não cria contas, não correlaciona dados entre tenants. Só pesquisador humano pega.

Em SaaS B2B brasileiro que auditamos em 2026, BOLA em pelo menos 1 endpoint aparece em cerca de 85% dos engagements.

Como corrigir — defense in depth em 4 camadas

Camada 1: Middleware de tenant scoping

Decorator ou middleware que valida ownership automaticamente:

• @tenant_scoped(resource='card', param='card_id') antes da view
• Validação automática antes de qualquer lógica da view executar
• Centraliza autorização em 1 lugar — não depende do dev lembrar

Camada 2: Query com filter obrigatório

Toda query SQL relacionada a recurso de tenant deve incluir tenant_id em WHERE:

• SELECT * FROM transactions WHERE card_id = $1 AND tenant_id = $2
• Lint de SQL ou helper de ORM que rejeita query sem tenant_id

Camada 3: Row-Level Security (PostgreSQL)

Defense in depth no banco: PostgreSQL nativo bloqueia via CREATE POLICY tenant_isolation. Se Camada 1 falhar e Camada 2 falhar, a Camada 3 ainda protege.

Camada 4: Testes automatizados de autorização no CI

Suite de testes que cria 2 contas em tenants diferentes e tenta acesso cruzado em cada endpoint sensível. Pipeline falha se BOLA for introduzido em PR. Esse é o controle preventivo definitivo.

O custo de não corrigir

No caso real, calculamos:

• Volume de dados expostos se explorado: ~12M transações (toda a base ativa)
• Categoria LGPD: dado pessoal financeiro (alta sensibilidade)
• Multa LGPD máxima: R$ 50M (cap por incidente)
• Custo de comunicação: notificação obrigatória à ANPD + todos titulares afetados
• Custo de litígio: ações coletivas (Procon, ações civis públicas)
• Churn estimado: 4 em cada 10 clientes brasileiros não voltam após incidente (Akamai, 2024)

O bug foi corrigido em 72h após o nosso relatório. Nunca foi explorado por atacante real, pelo que se sabe.

O que fazer hoje

Se sua plataforma é multi-tenant (SaaS B2B, fintech, marketplace, e-commerce com lojistas, healthtech com clínicas):

1. Auditoria de endpoints que recebem ID/UUID — liste todos manualmente
2. Para cada um, valide: existe filtro de tenant_id no servidor?
3. Se não tem certeza: contrate pentest focado em BOLA cross-tenant
4. Implemente as 4 camadas acima como padrão arquitetural

Se você é founder/CTO e está pensando “isso não pode acontecer com a gente, nosso time é bom” — é exatamente o que dizem todos os times que descobrem BOLA em produção 6 meses depois.

A diferença entre time bom e time vulnerável não é talento — é processo de validação adversarial.

Para conversar sobre pentest focado em multi-tenant isolation, veja as páginas dedicadas: /pentest-fintech, /pentest-saas e /pentest-marketplace. Para entender mais sobre as classes de falha que dominam APIs em 2026, veja BOLA, BOPLA e BFLA.