O Brasil construiu, em poucos anos, o ecossistema de finanças abertas mais avançado do mundo. Segundo o relatório Estado do Open Finance – Brasil & Mundo, divulgado pela Sensedia em parceria com a Let’s Money em janeiro de 2026, o país alcançou a marca de 128 milhões de consentimentos ativos, colocando-se à frente de outras 78 nações com regulação do setor. Essa infraestrutura movimenta mais de 4,4 bilhões de comunicações semanais entre instituições financeiras, fintechs e iniciadores de pagamento.
Esse volume é a prova de que o modelo funciona. Mas também é a medida exata de algo que costuma passar despercebido nas discussões sobre inovação: cada consentimento representa uma chamada de API, e cada API é, em potencial, um ponto de entrada. O Open Finance e o Pix não apenas aceleraram a experiência do usuário financeiro brasileiro, eles redesenharam, silenciosamente, o que significa proteger uma instituição.
Essa superfície de exposição é composta por APIs REST protegidas principalmente por OAuth 2.0, OpenID Connect (OIDC) e pelo Financial-grade API (FAPI), padrão adotado pelo Open Finance brasileiro. A segurança desse ecossistema depende não apenas da criptografia ou da autenticação, mas da proteção contínua do ciclo de vida das APIs e de seus mecanismos de autorização.
De um perímetro controlado para um ecossistema de confiança distribuída
Até pouco tempo, a segurança de uma instituição financeira podia ser descrita, de forma simplificada, como o controle de um perímetro: a instituição definia o fluxo de onboarding, geria as sessões de seus próprios usuários e concentrava a lógica de decisão dentro de sistemas que ela mesma operava. Esse modelo permitia previsibilidade. O risco tinha endereço.
O Open Finance rompeu essa lógica por definição, não por falha de implementação. Uma transação de crédito iniciada em uma fintech pode depender de dados hospedados por um banco tradicional, validados por um iniciador de pagamentos e confirmados por meio de um token trafegando entre múltiplas infraestruturas. O risco passou a acompanhar a transação, e não mais a instituição. Essa mudança estrutural é reconhecida pelo próprio setor: como aponta análise publicada pelo Jornal Empresas & Negócios, o aumento da quantidade de “portas e janelas abertas” fez com que instituições financeiras passassem a depender também da segurança de parceiros terceiros, já que o Open Finance funciona sobre uma malha de APIs que conecta bancos, fintechs e iniciadores de pagamentos.
Esse modelo aproxima o setor financeiro da arquitetura Zero Trust, na qual nenhuma requisição é considerada confiável apenas por estar autenticada. Cada chamada deve ser validada continuamente considerando identidade, contexto, dispositivo, comportamento e nível de risco.
Cada nova integração aprovada é, ao mesmo tempo, um ganho de competitividade e um novo ponto de exposição. Essa dualidade é o centro do problema que a maioria dos programas de segurança ainda não resolveu.
As APIs dobraram como superfície de ataque testada
Os números que confirmam essa mudança de eixo já aparecem em dados de mercado. De acordo com o relatório Inside Pentesting 2026, produzido pela Vantico com base em centenas de projetos de teste de intrusão conduzidos em 2025, as APIs praticamente dobraram como proporção da superfície de ataque avaliada em pentests, saltando de 5,6% dos projetos em 2024 para 11,2% em 2025. No setor financeiro, onde o Open Finance e as integrações via Pix multiplicam o número de endpoints expostos, esse crescimento tende a ser ainda mais acentuado do que a média geral do mercado.
Esse crescimento também acompanha o aumento de vulnerabilidades descritas pelo OWASP API Security Top 10, especialmente Broken Object Level Authorization , Broken Authentication, Excessive Data Exposure e Unrestricted Resource Consumption, que figuram entre as principais causas de comprometimento de APIs modernas.
O mesmo estudo aponta que falhas de autenticação (Authentication Failures) ocupam a segunda posição no ranking de vulnerabilidades mais identificadas, respondendo por 10,9% do total encontrado nos projetos analisados. Em um ambiente onde identidade equivale, na prática, a autorização, uma falha na camada de autenticação de uma API não é um detalhe técnico isolado: é a porta para movimentações fraudulentas em tempo real.
Na prática, esses incidentes frequentemente envolvem reutilização indevida de tokens OAuth, replay de sessões, abuso de refresh tokens, interceptação do fluxo Authorization Code e falhas na validação de escopos (Scopes).
Há ainda um dado que expõe o custo da inação: em 27% dos casos analisados pela Vantico, vulnerabilidades classificadas como altas permanecem abertas por mais de 70 dias mesmo após a entrega do relatório de pentest. A causa mais comum não é falta de conhecimento técnico, é a dificuldade de integrar a correção ao ritmo operacional da instituição. Para um setor sob pressão regulatória constante, esse intervalo é tempo suficiente para que uma vulnerabilidade conhecida se transforme em incidente.
Os vetores que exploram a velocidade do ecossistema
A combinação de Open Finance e Pix criou um conjunto de ameaças que não se comporta como os ataques tradicionais de rede ou de endpoint. Elas exploram justamente a interoperabilidade que torna o sistema valioso.
O phishing de consentimento é um exemplo direto: em vez de tentar comprometer um sistema, o atacante induz o próprio usuário a autorizar o compartilhamento de dados ou a aprovar uma iniciação de pagamento fraudulenta, explorando a familiaridade que o consumidor brasileiro já tem com telas de autorização do Open Finance. Também crescem tentativas de takeover de conta entre instituições diferentes, quando uma credencial comprometida em uma fintech é usada para tentar acesso a serviços de outra instituição dentro da mesma malha de integrações, e episódios de sequestro ou abuso de endpoints de API, em que falhas de limitação de requisições ou de validação contextual permitem ataques de força bruta, credential stuffing ou manipulação de sessão.
O denominador comum entre esses vetores é a engenharia social amplificada pela velocidade. O Pix, sistema que movimentou R$ 35,4 trilhões em 2025, tornou-se também um vetor de manipulação: entre 80% e 90% das fraudes atuais que envolvem o sistema dependem de convencer a vítima a autorizar a própria transação, e não de invadir tecnicamente um sistema. Esse padrão se replica no Open Finance, onde a urgência e o volume de solicitações legítimas de consentimento tornam mais fácil camuflar uma tentativa fraudulenta entre dezenas de autorizações rotineiras.
A escala regional reforça a gravidade desse cenário: segundo dados do CISO Advisor de 2026, enquanto a fraude por identidade sintética representa 11% dos casos globalmente, na América Latina esse índice chega a 48,3%, alimentado por bases de dados expostas e pela velocidade de adoção dos serviços digitais.
Por que proteger uma API exige uma abordagem diferente
Um firewall de rede foi desenhado para inspecionar tráfego. Um EDR foi desenhado para observar o comportamento de processos em um endpoint. Nenhum dos dois foi construído para entender o que é, de fato, uma chamada de API legítima entre um banco e um agregador de dados financeiros, uma sequência de requisições que simula um comportamento normal, mas está sendo usada para enumerar contas, ou um token de acesso válido sendo reutilizado de forma anômala.
A segurança de API exige visibilidade sobre o ciclo de vida completo do endpoint, desde a descoberta de APIs não documentadas (“shadow APIs”) até a análise comportamental do tráfego ao longo do tempo, capaz de identificar quando um padrão de uso, ainda que tecnicamente autenticado, foge do esperado. É exatamente esse o ponto cego que a maioria dos programas de segurança do setor financeiro ainda trata como item secundário, atrás de prioridades mais tradicionais como proteção de endpoint e gestão de identidade interna, quando a própria API já se consolidou como o novo perímetro da instituição.
Como a Asper estrutura a proteção do ciclo de vida das APIs
Diante desse cenário, a resposta da Asper para instituições financeiras que operam em ambientes de Open Finance e Pix se apoia em três frentes integradas, orquestradas pelo Cyber Fusion Center (CFC).
A primeira é o monitoramento contínuo do ciclo de vida das APIs, viabilizado pelo Salt. A plataforma acompanha o comportamento de cada endpoint exposto nas integrações de Open Finance e Pix, identificando padrões anômalos de tráfego, tentativas de sequestro e abuso de funcionalidades antes que evoluam para incidentes de fraude ou vazamento de dados. Diferentemente de ferramentas voltadas para tráfego de rede genérico, o Salt entende o contexto específico de uma API financeira, o que permite distinguir uma variação de uso legítima de uma tentativa de exploração.
A segunda frente é o mapeamento e a priorização de exposição com o Tenable One, que identifica e classifica vulnerabilidades em ativos expostos externamente, incluindo as próprias APIs, dentro de uma visão unificada de gerenciamento de exposição. Em vez de tratar cada vulnerabilidade isoladamente, a plataforma permite priorizar correções com base no risco real que cada exposição representa para o negócio, um fator determinante quando, como mostram os dados do setor, vulnerabilidades críticas podem permanecer abertas por meses.
A terceira frente é a correlação de inteligência dentro do Cyber Fusion Center, que conecta os alertas de tráfego de API ao contexto mais amplo de ameaças, cruzando comportamentos suspeitos de consentimento, tentativas de takeover entre instituições e padrões de fraude conhecidos. É essa correlação humana e tecnológica, e não apenas a soma de ferramentas, que permite identificar em tempo real quando uma sequência de chamadas aparentemente legítimas está, na verdade, orquestrando uma fraude.
Segurança de API como decisão de design, não como economia
O Open Finance e o Pix não são um risco a ser eliminado, são a infraestrutura que posiciona o sistema financeiro brasileiro como referência global. O problema não está na existência das APIs, está em tratá-las como um detalhe de integração em vez de reconhecê-las como o novo perímetro da instituição.
À medida que Open Finance, Pix Automático, Open Insurance e novos ecossistemas financeiros ampliam o número de integrações, API Security deixa de ser um componente operacional e passa a representar um requisito estratégico para resiliência cibernética, prevenção a fraudes e conformidade regulatória. Proteger APIs significa proteger identidades, consentimentos, transações e a confiança que sustenta todo o ecossistema financeiro digital.
Os números deixam pouca margem para dúvida: a superfície de ataque testada em APIs dobrou em um ano, as falhas de autenticação já ocupam a segunda posição entre as vulnerabilidades mais recorrentes, e o volume de consentimentos ativos segue crescendo em ritmo acelerado. Cada uma dessas curvas aponta na mesma direção. Ignorar a segurança de API no desenho de uma arquitetura de Open Finance não é uma economia, é uma decisão de risco que a instituição está assumindo, ainda que não tenha sido formalmente tomada por ninguém.
Instituições que já enfrentam as exigências regulatórias do Banco Central em relação a testes de segurança podem aprofundar o tema no artigo O que é Pentest? Entenda o teste de intrusão que o Banco Central já exige das instituições financeiras, publicado no blog da Asper.
Quer entender como o Cyber Fusion Center da Asper pode mapear e proteger as APIs expostas pela sua instituição no ecossistema de Open Finance e Pix? Fale com nosso time de especialistas.
