API Security em Open Finance: As Vulnerabilidades Que Hackers Já Exploram

Você acorda, abre o app do seu banco e descobre que seu limite de crédito e extrato dos últimos 12 meses foram baixados 400 vezes na madrugada. Não por você, claro. Um script automatizado rodando a partir de um proxy na Rússia encontrou um endpoint desprotegido na API de uma fintech onde você autorizou o compartilhamento de dados no ano passado. Essa não é uma sinopse de ficção científica. Essa é a realidade brutal e silenciosa do Open Finance brasileiro hoje, em pleno 2026.

Nós acompanhamos a evolução do sistema financeiro aberto desde a fase 1. Vimos o Banco Central empurrar as instituições tradicionais para a era digital a força, enquanto fintechs surfavam a onda da inovação. O resultado prático? Um ecossistema vibrante com mais de 50 milhões de consentimentos ativos, mas também a maior superfície de ataque já construída na história financeira do país.

Dados consolidados de mercado apontam que as chamadas de API no Brasil saltaram de 2 bilhões mensais em 2023 para mais de 15 bilhões agora. Onde há volume colossal de requisições, há predadores testando maçanetas. E a verdade nua e crua é que muitas dessas portas estão, na melhor das hipóteses, trancadas com fechaduras baratas. Se você opera uma fintech, um e-commerce integrado ou uma instituição de pagamento, preste atenção aqui. O jogo mudou. Os hackers não estão mais mandando e-mails falsos fingindo ser a Receita Federal; eles estão conversando diretamente com os seus servidores via JSON.

O Calcanhar de Aquiles: Autorização Quebrada (BOLA/IDOR)

A vulnerabilidade número um no Open Finance brasileiro atende pela sigla BOLA (Broken Object Level Authorization), historicamente conhecida como IDOR (Insecure Direct Object Reference). Ela lidera o ranking do OWASP API Security Top 10 e é a causa raiz de vazamentos massivos que as empresas tentam abafar sob a desculpa de "instabilidade sistêmica".

Como funciona na prática

Imagine um restaurante badalado. O segurança na porta (Autenticação) checa seu documento e deixa você entrar. O garçom (a API) anota seu pedido e traz a comida. Mas se você disser ao garçom "traga a lagosta da mesa 4 para a minha mesa", e ele trouxer sem verificar se você pagou por aquilo ou se você conhece quem está na mesa 4, temos uma falha de Autorização. O garçom confiou cegamente no seu comando.

Nas APIs financeiras, isso acontece quando um aplicativo envia uma requisição legítima para buscar o saldo de uma conta: GET /api/v1/accounts/12345/balances. O usuário está autenticado, tem um token válido. Tudo parece normal. Mas o hacker intercepta essa requisição no meio do caminho e altera o ID numérico: GET /api/v1/accounts/12346/balances.

Se o backend da fintech não validar estritamente se o Token de quem pediu pertence exatamente ao dono da conta 12346, a API retorna o saldo de um desconhecido. Observamos dezenas de implementações recentes onde desenvolvedores assumem que, se o usuário passou pelo gateway de API, ele tem permissão para tudo. Scripts simples varrem números sequenciais de contas em minutos, extraindo terabytes de dados bancários sigilosos antes que o time de SecOps termine de tomar o primeiro café do dia.

Autenticação Falha e Vazamento de Tokens (OAuth 2.0)

O Open Finance brasileiro exige o uso do padrão FAPI (Financial-grade API), um perfil altamente restritivo do OAuth 2.0 e OpenID Connect. Gigantes como Nubank, Mercado Pago e Itaú gastam milhões garantindo conformidade com o FAPI. A vulnerabilidade mora nas bordas do ecossistema: a corretora de nicho ou a fintech de crédito consignado que terceirizou o desenvolvimento e não configurou o Mutual TLS (mTLS) corretamente.

O pesadelo dos tokens forjados

APIs usam JSON Web Tokens (JWT) para saber quem é quem após o login. Um JWT é como um crachá de visitante assinado criptograficamente. O problema? Hackers descobriram que muitas APIs aceitam o algoritmo "None" no cabeçalho do token. O invasor pega o próprio token, altera seu nível de privilégio para "admin", remove a assinatura criptográfica, muda o cabeçalho para "alg": "none" e manda para o servidor.

APIs mal configuradas leem a instrução "none", pulam a verificação de assinatura e aceitam o token falsificado. Outro vetor comum é a má gestão de Refresh Tokens. Se um hacker compromete o dispositivo de um usuário e rouba um refresh token que nunca expira (ou expira em prazos absurdos, como 6 meses), ele ganha acesso perpétuo àquela conta via API, drenando dados de Open Finance continuamente, mesmo após o usuário trocar a senha principal do banco.

Atribuição em Massa (Mass Assignment)

Os frameworks de desenvolvimento modernos, como Spring Boot (Java) ou Express (Node.js), são projetados para fácilitar a vida do programador. Eles pegam um objeto JSON enviado pelo cliente e o vinculam automaticamente aos campos do banco de dados. Essa mágica técnica cria uma das brechas mais perigosas do setor.

Digamos que um usuário vai atualizar seu perfil em um app de pagamentos. O app envia um JSON para a API: {"email": "cliente@email.com", "telefone": "11999999999"}.

Um atacante observador estuda a documentação da API (muitas vezes deixada exposta acidentalmente via Swagger) e adivinha os campos internos do banco de dados. Ele envia a mesma requisição, mas injeta campos extras: {"email": "cliente@email.com", "telefone": "11999999999", "kyc_verified": true, "credit_limit": 50000}.

Se o desenvolvedor não aplicou uma lista branca rigorosa (allowlist) de quais campos podem ser alterados pelo cliente, o framework injeta esses dados direto no banco. O hacker acaba de aprovar sua própria verificação de identidade (KYC) e se auto-concedeu um limite de crédito de 50 mil reais. Nós flagramos essa exata técnica sendo vendida em fóruns da dark web focados no mercado brasileiro no final de 2025.

Raté Limiting e Scraping Avançado

Outro mito perigoso é achar que ataques de negação de serviço (DDoS) se resumem a derrubar a infraestrutura com volume bruto. O ataque moderno nas APIs de Open Finance é cirúrgico, lento e silencioso.

Hackers usam redes de proxies residenciais brasileiros — milhares de endereços IP legítimos de provedores como Claro, Vivo e Oi — para fazer requisições lentas. Uma chamada a cada 30 segundos. Eles buscam raspar dados de taxas de juros, testar CPFs vazados contra APIs de onboarding, ou tentar ataques de força bruta em chaves de autenticação.

Como o tráfego não gera picos de rede, as regras padrão de Web Application Firewalls (WAF) não disparam alarmes. A fintech só percebe o ataque no fim do mês, quando a conta da nuvem na AWS ou Azure chega multiplicada por cinco devido ao custo de processamento das lambdas e consultas ao banco de dados. O prejuízo é financeiro e operacional.

Implicações Práticas: O que isso significa para a sua operação

Se você acha que um WAF configurado no padrão de fábrica vai segurar um ataque direcionado de API, você está jogando roleta russa com o CNPJ da sua empresa. A regulamentação brasileira é implacável com falhas de segurança nesse nível.

Na prática, um vazamento de dados provocado por uma API exposta aciona imediatamente dois rolos compressores regulatórios. Primeiro, a Autoridade Nacional de Proteção de Dados (ANPD) entra em cena com multas baseadas na LGPD, que podem chegar a R$ 50 milhões por infração. Segundo, e muito pior para o negócio, o Banco Central aplica sanções baseadas na Resolução Conjunta nº 6 (antiga 277). O BACEN tem o poder de suspender a participação da sua instituição no Open Finance e no PIX. Cortar o acesso de uma fintech ao PIX hoje é uma sentença de morte instantânea.

A responsabilidade técnica exige ferramentas específicas de API Security Posture Management (ASPM). Não adianta testar vulnerabilidades apenas no ambiente de homologação. O código que estava seguro na sexta-feira pode se tornar vulnerável no sábado após um deploy não documentado de um desenvolvedor júnior tentando resolver um bug de fim de semana.

O Futuro da Defesa: Para onde o mercado caminha

A corrida de gato e rato entre cibercriminosos e instituições financeiras atingiu um novo patamar tecnológico. Bancos e grandes adquirentes estão abandonando as defesas baseadas apenas em regras estáticas (como IPs bloqueados ou assinaturas conhecidas) e migrando agressivamente para análise comportamental baseada em Inteligência Artificial.

O futuro da segurança em APIs no ecossistema FAPI envolve entender o contexto da requisição. A IA passa a analisar o padrão: este usuário sempre acessa via celular de São Paulo às 10h da manhã. Por que agora sua chave de API está sendo usada a partir de um data center na Europa às 3h da madrugada, solicitando um volume de dados 40 vezes maior que sua média histórica? O sistema bloqueia a transação na camada de aplicação antes mesmo da requisição chegar ao banco de dados.

A transição para o Zero Trust em APIs não é mais um luxo para teses de arquitetura; tornou-se o custo mínimo de entrada para operar dinheiro e dados de brasileiros. Proteger endpoints hoje garante que sua fintech continue existindo amanhã. A caça às bruxas nas APIs já começou. Garanta que a sua casa esteja em ordem.