Segurança de APIs em fintechs e Open Finance: do OAuth2 ao OWASP API Top 10 na prática

Por que a API é a superfície de ataque crítica de uma fintech

Uma fintech moderna é, na prática, um conjunto de APIs. O app mobile, o internet banking, parceiros, gateways de pagamento e, no Brasil, todo o ecossistema de Open Finance conversam por HTTP/JSON. Diferente de um site institucional, essas APIs expõem operações de movimentação financeira, consulta de saldo, dados cadastrais e PII reguladas pela LGPD. O resultado é uma superfície onde uma única falha de autorização pode significar acesso a contas de terceiros ou transações não autorizadas.

O OWASP API Security Top 10 (edição 2023) consolidou o que diferencia o risco de API do risco web tradicional. As falhas dominantes deixaram de ser injeção e XSS e passaram a ser de lógica de autorização: API1 BOLA (Broken Object Level Authorization), API2 Broken Authentication, API3 Broken Object Property Level Authorization e API5 Broken Function Level Authorization. São falhas que scanners genéricos raramente detectam, porque dependem do contexto de negócio: o scanner não sabe que a conta 1042 não pertence ao usuário autenticado.

Para um CTO de fintech, isso muda a estratégia de defesa. Não basta TLS, WAF e um portão de login. O modelo de ameaça precisa assumir que o atacante é um cliente autenticado legítimo que tenta acessar recursos de outros clientes, escalar privilégios ou abusar de endpoints. A norma NIST SP 800-204 (Security Strategies for Microservices) reforça esse princípio: autorização deve ser aplicada o mais próximo possível do recurso, e nunca delegada exclusivamente ao gateway ou ao frontend.

Autenticação: OAuth2, OpenID Connect e o perfil FAPI do Open Finance Brasil

Autenticação responde a uma pergunta: quem está fazendo esta chamada? Em APIs de fintech o padrão de fato é OAuth2 para autorização de acesso e OpenID Connect (OIDC) para identidade. O erro recorrente é tratar o access token como prova de identidade do usuário final (ele não é) ou aceitar tokens sem validar assinatura, emissor (iss), audiência (aud) e expiração (exp). Tokens opacos com introspecção ou JWTs assinados e validados em cada serviço são abordagens válidas; o que não se admite é confiar em um token sem verificação criptográfica.

No Open Finance Brasil o nível de exigência sobe. O ecossistema adota o perfil FAPI (Financial-grade API) 1.0 Advanced da OpenID Foundation. Na prática isso obriga: PAR (Pushed Authorization Requests) para não trafegar parâmetros sensíveis pela URL; PKCE no fluxo de autorização; autenticação do cliente por mTLS ou private_key_jwt em vez de client_secret simples; e sender-constrained tokens, em que o access token fica vinculado ao certificado mTLS do cliente, de modo que um token roubado não funciona em outra conexão. Respostas e requests de consentimento são assinados (JWS), garantindo integridade ponta a ponta.

A infraestrutura de confiança do Open Finance Brasil depende do Diretório de Participantes e de certificados ICP/Brasil e do PKI do ecossistema. Implementações comuns falham ao não validar a cadeia de certificados corretamente, ao aceitar tokens com escopo (scope) mais amplo que o consentimento concedido, ou ao não amarrar o consentimento (consent_id) à transação efetivamente executada. Cada um desses pontos é um vetor de autorização indevida disfarçado de problema de autenticação.

Recomendações concretas: access tokens de vida curta com refresh tokens rotacionados; nunca aceitar o algoritmo none em JWT; fixar a allowlist de algoritmos de assinatura no servidor; e validar aud para que um token emitido para um serviço não seja aceito por outro. Para o usuário final, MFA resistente a phishing (WebAuthn/FIDO2) no fluxo de autorização reduz drasticamente o sequestro de sessão.

Autorização e BOLA/IDOR: a falha que mais derruba fintechs

BOLA, também conhecida como IDOR (Insecure Direct Object Reference), ocorre quando a API expõe um identificador de objeto (uma conta, um pagamento, um documento) e não verifica se o token autenticado tem direito sobre aquele objeto específico. Um endpoint como GET /v1/accounts/{accountId}/transactions que apenas confere se há um token válido, mas não se aquele token pertence ao dono de accountId, permite que qualquer cliente leia os dados de qualquer conta apenas trocando o ID. É a falha API1 do OWASP e a campeã de impacto em fintech.

A defesa é arquitetural e disciplinada. A verificação de propriedade do objeto deve acontecer na camada de serviço, junto à consulta de dados, e ser derivada do token, nunca de um parâmetro controlado pelo cliente. Não confie em IDs sequenciais como controle de segurança (UUIDs não substituem checagem de autorização, apenas dificultam enumeração). Centralize a decisão de acesso em um motor de políticas (ABAC/ReBAC, por exemplo com OPA/Rego) para evitar que cada desenvolvedor reimplemente a regra de forma inconsistente.

BOLA tem irmãs igualmente perigosas. API3 (Broken Object Property Level Authorization) inclui mass assignment, quando o cliente envia campos extras no corpo (por exemplo role ou balance) que são persistidos sem validação, e excessive data exposure, quando a API retorna o objeto inteiro e deixa o frontend filtrar. Use DTOs explícitos de entrada e de saída: aceite apenas os campos esperados e serialize apenas os campos autorizados. API5 (Broken Function Level Authorization) cobre o acesso a funções administrativas por usuários comuns, comum quando rotas /admin dependem só de obscuridade.

Esse é exatamente o tipo de falha que um pentest de API encontra e um scanner automatizado não. Validar autorização por objeto exige entender o modelo de negócio, criar dois usuários legítimos e tentar, com o token de um, acessar os recursos do outro em cada endpoint. É um trabalho de segurança ofensiva orientado a contexto.

Rate limiting, validação de entrada e segredos

API4 (Unrestricted Resource Consumption) trata de abuso de recursos: endpoints sem limite permitem brute force de credenciais e OTPs, scraping de dados, fraude por tentativa e negação de serviço. Aplique rate limiting por cliente autenticado, por IP e por endpoint sensível, com limites diferenciados para operações de escrita e de leitura. Em fluxos de pagamento e autenticação, combine throttling com bloqueio progressivo e detecção de anomalia. Limite também o tamanho de payload, profundidade de objetos JSON e paginação máxima para conter consumo de CPU e memória.

Validação de entrada é a base contra injeção e corrupção de dados. Adote allowlist por schema: valide cada request contra um contrato OpenAPI/JSON Schema na borda, rejeitando o que não casa, em vez de tentar limpar entrada maliciosa. Use sempre consultas parametrizadas no banco e bibliotecas que tratam o tipo de dado esperado. API8 (Security Misconfiguration) lembra que CORS permissivo, mensagens de erro verbosas com stack trace, métodos HTTP não usados habilitados e headers de segurança ausentes ampliam a superfície sem necessidade.

Gestão de segredos é onde muitas startups acumulam dívida. Chaves de API, credenciais de banco, certificados mTLS e chaves de assinatura JWT não podem viver em repositório, em variáveis de ambiente versionadas ou em logs. Use um cofre (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) com rotação automática e acesso por identidade de workload, alinhado às diretrizes do NIST SP 800-57 para gerenciamento de chaves. Habilite secret scanning no CI para barrar vazamentos antes do merge, e trate qualquer segredo exposto como comprometido: rotacione, não apenas remova do histórico.

Logging, observabilidade e detecção sem vazar dados

API9 (Improper Inventory Management) e API10 (Unsafe Consumption of APIs) apontam para dois pontos cegos: você não defende o que não conhece, e confiar cegamente em APIs de terceiros propaga risco. Mantenha um inventário vivo de todas as APIs, versões e ambientes, marcando endpoints obsoletos (shadow e zombie APIs) que continuam no ar sem manutenção. Para integrações de terceiros e parceiros do Open Finance, valide respostas com o mesmo rigor das entradas e não siga redirecionamentos cegamente.

Logging é controle de segurança e requisito de auditoria, mas precisa ser feito com cuidado. Registre eventos de autenticação, autorização negada, mudanças de consentimento e operações financeiras com identificadores correlacionáveis (trace/correlation ID), preservando a capacidade de reconstruir uma sessão durante investigação. Ao mesmo tempo, nunca registre tokens, senhas, PAN completo, chaves Pix ou PII em texto claro: aplique masking e redação na origem. A NIST SP 800-92 (Guide to Computer Security Log Management) e os princípios de minimização da LGPD orientam esse equilíbrio.

Detecção depende de logs estruturados e centralizados alimentando um SIEM com regras para os padrões de ataque a API: picos de 401/403, tentativas sequenciais de IDs (assinatura de BOLA), uso de token fora do binding mTLS, e desvio de volume por cliente. Métricas de latência e erro por endpoint também antecipam abuso. O objetivo é reduzir o tempo entre comprometimento e detecção, métrica que define o impacto real de um incidente.

Como a Decripte ajuda a fechar o ciclo

Política de segurança só vira garantia quando é testada sob ataque. A Decripte atua na ponta ofensiva: pentest de APIs com foco no que importa para fintech, BOLA/IDOR endpoint a endpoint, falhas de autorização funcional, validação dos fluxos OAuth2/OIDC e conformidade prática com o perfil FAPI do Open Finance Brasil. Em vez de um relatório genérico de scanner, a entrega é a prova de que um cliente autenticado não consegue cruzar a fronteira dos dados de outro.

Encontrar a falha é metade do trabalho. Com a gestão de vulnerabilidades da Decripte, os achados entram em um ciclo contínuo de priorização por risco real, acompanhamento de correção e reteste, integrado ao fluxo de engenharia. Isso evita que o pentest vire um PDF esquecido e mantém a postura de segurança acompanhando o ritmo de deploy de uma startup.

Para equipes que estão começando a estruturar segurança, a Decripte oferece um plano gratuito, um ponto de entrada para mapear a superfície de APIs e ganhar visibilidade sem barreira inicial. Conforme a fintech cresce e o escopo regulatório aperta, a parceria evolui do diagnóstico para a validação ofensiva recorrente e a gestão contínua do risco.

Checklist prático

1. 1

   1. Inventarie e contrate suas APIs

   Liste todas as APIs, versões e ambientes; documente cada endpoint em um contrato OpenAPI e elimine shadow/zombie APIs que estão no ar sem manutenção.

2. 2

   2. Padronize autenticação forte

   Use OAuth2/OIDC com validação completa de assinatura, iss, aud e exp; no Open Finance, implemente FAPI 1.0 Advanced (PAR, PKCE, mTLS ou private_key_jwt, sender-constrained tokens).

3. 3

   3. Aplique autorização por objeto

   Em todo endpoint que recebe um ID, verifique na camada de serviço se o token autenticado é dono do recurso; centralize as regras em um motor de políticas para evitar BOLA/IDOR.

4. 4

   4. Controle entrada e saída de dados

   Valide cada request contra JSON Schema, use DTOs explícitos para bloquear mass assignment e exponha apenas os campos autorizados na resposta.

5. 5

   5. Limite consumo e proteja segredos

   Configure rate limiting por cliente e endpoint, limite o tamanho de payload e armazene chaves e certificados em cofre com rotação automática; ative secret scanning no CI.

6. 6

   6. Registre e monitore com segurança

   Centralize logs estruturados com correlation ID, mascare PII e segredos na origem e crie alertas no SIEM para picos de 403, enumeração de IDs e uso de token fora do binding.

7. 7

   7. Teste sob ataque e itere

   Realize pentest de API focado em autorização e fluxos OAuth2/FAPI, alimente a gestão de vulnerabilidades com os achados e faça reteste após cada correção.

Perguntas frequentes