Segurança de APIs no Open Finance: FAPI e mTLS

No Open Finance, a segurança de APIs é o teste que comprova a resistência das interfaces de dados e pagamento aos ataques que exploram autenticação, autorização e consentimento. Ele avalia o perfil FAPI, o mTLS, o Dynamic Client Registration (DCR) e a jornada de consentimento como um adversário faria — forjando tokens, reutilizando consentimentos e escalando escopos.

Por que a API é o perímetro no Open Finance?

O Open Finance Brasil eliminou a fronteira de rede como principal linha de defesa. Dados sensíveis e a capacidade de iniciar pagamentos circulam entre dezenas de instituições participantes por meio de APIs padronizadas, e a confiança entre elas é sustentada por criptografia, certificados e um perfil de autenticação rígido — não por um firewall.

Isso muda a natureza do risco. Em uma integração ponto a ponto, uma falha afeta duas partes. No ecossistema, uma única instituição que exponha uma interface mal protegida amplia a superfície de ataque de todos os participantes conectados a ela. Uma autorização quebrada deixa de ser um problema local e passa a ter impacto sistêmico: pode expor dados financeiros de milhares de titulares ou permitir a iniciação fraudulenta de pagamentos.

Por isso o teste de segurança de APIs no Open Finance não é um exercício isolado sobre um endpoint. Ele parte do papel da instituição no ecossistema — transmissora, receptora ou iniciadora de pagamento — e avalia cada camada do padrão contra abuso, vazamento e fraude.

O que o perfil FAPI exige e onde ele falha?

FAPI (Financial-grade API) é o perfil de segurança da OpenID Foundation adotado pelo Open Finance Brasil. Ele endurece o OAuth 2.0 e o OpenID Connect com um conjunto de mecanismos que, juntos, dificultam o roubo e o reuso de tokens. O teste verifica se a implementação realmente cumpre o perfil — ou apenas o declara na documentação.

Os controles que avaliamos com mais frequência no perfil FAPI 1.0 Advanced:

• PKCE (Proof Key for Code Exchange) — impede a interceptação do código de autorização; verificamos se o code_verifier é realmente validado e não apenas aceito.
• PAR (Pushed Authorization Requests) — move os parâmetros da requisição para um canal servidor a servidor; testamos se o endpoint aceita requisições de autorização fora do fluxo PAR.
• JARM (JWT Secured Authorization Response Mode) — protege a integridade da resposta de autorização; validamos a verificação de assinatura.
• Sender-constrained tokens — amarram o access token ao certificado do cliente, de modo que um token roubado não sirva para outra parte.
• Assinatura de mensagem — verificamos se as mensagens de requisição e resposta são assinadas e se as assinaturas são efetivamente validadas.

A falha mais comum não é a ausência de um controle, e sim sua validação incompleta. Uma implementação que aceita o token mesmo quando a assinatura não confere, ou que não verifica o vínculo entre o token e o certificado, cumpre o perfil no papel e o viola na prática. É exatamente esse tipo de brecha que só aparece quando alguém tenta contorná-la de forma orientada, e não em uma checagem de conformidade documental.

Como o mTLS e os certificados são testados?

O mTLS (mutual TLS) é a base da confiança entre participantes: cada lado apresenta um certificado emitido dentro da cadeia do diretório do Open Finance, e a conexão só se estabelece quando ambos são validados. O access token, por sua vez, é vinculado ao certificado do cliente — o sender-constrained token — para que um token capturado não possa ser reaproveitado por um terceiro.

A avaliação dessa camada cobre três pontos:

1. Autenticação mútua — confirmamos que o servidor exige e valida o certificado do cliente, e que não há um caminho alternativo que aceite a conexão sem ele.
2. Cadeia de certificados — verificamos se a validação respeita a cadeia emitida pelo diretório de participantes, sem aceitar certificados autoassinados, expirados ou revogados.
3. Vínculo token-certificado — testamos se o access token realmente exige o certificado ao qual foi emitido, tentando usá-lo a partir de outro cliente. Se o token funciona sem o certificado original, a proteção sender-constrained está apenas nominalmente presente.

Quando esse vínculo não é validado, todo o esforço do perfil FAPI para evitar o reuso de tokens é anulado — um único token vazado passa a valer como credencial reutilizável.

Onde o Dynamic Client Registration abre porta para abuso?

O Dynamic Client Registration (DCR) permite que instituições participantes registrem clientes de forma automatizada, a partir de software statements assinados pelo diretório. É um mecanismo necessário à escala do ecossistema, mas concentra risco: quem controla o registro define escopos, identidade e capacidades do cliente.

Os vetores de abuso que investigamos:

• Validação frouxa do software statement — se a assinatura ou os campos do statement não são verificados rigorosamente, torna-se possível registrar um cliente com atributos indevidos.
• Elevação de escopo no registro — tentativas de registrar um cliente com escopos além dos autorizados para o papel da instituição.
• Confusão de identidade — falhas que permitam a um participante assumir, no registro, a identidade de outro, herdando sua confiança no ecossistema.
• Ciclo de vida do cliente — atualização e revogação de clientes registrados; verificamos se um cliente revogado perde de fato o acesso e se a atualização não reabre escopos.

Uma falha de DCR raramente aparece sozinha. Ela costuma ser o acesso inicial que habilita os demais ataques — de posse de um cliente registrado indevidamente, o adversário parte para a exploração de autorização nas APIs de dados e de pagamento.

Como a jornada de consentimento é atacada?

O consentimento é o controle que autoriza o compartilhamento de dados e a iniciação de pagamentos em nome do titular. Ele tem um ciclo de vida — criação, escopo, expiração e revogação — e cada transição é uma oportunidade de falha de lógica.

O que testamos na jornada de consentimento:

• Escopo — se os dados efetivamente acessados correspondem ao que o consentimento autorizou, sem alcançar recursos além do concedido.
• Reutilização — se um consentimento pode ser reaproveitado para uma finalidade ou uma sessão diferentes daquela em que foi concedido.
• Expiração — se o consentimento realmente deixa de valer após o prazo, ou se o acesso persiste.
• Revogação — o teste mais revelador: verificamos se os dados continuam acessíveis depois que o titular revoga o consentimento. Quando continuam, a revogação é um controle apenas visual.

Falhas de consentimento têm impacto direto sob a LGPD, porque tratam do compartilhamento de dados pessoais entre participantes sem base legal válida. Por isso mapeamos cada achado ao princípio correspondente e o conectamos ao programa de adequação à LGPD da instituição.

Quais são as falhas mais recorrentes no Open Finance?

A tabela abaixo reúne as categorias de achado que encontramos com mais frequência, o controle envolvido e o impacto típico quando a falha é explorada.

O ponto que une essas categorias é que quase nenhuma delas é detectada por uma varredura automatizada. Um scanner lista bibliotecas desatualizadas e cabeçalhos ausentes; ele não sabe que um consentimento deveria ter expirado, nem que um token não deveria funcionar a partir de outro cliente. As falhas de maior impacto no Open Finance são falhas de lógica e de autorização, e essas só se comprovam com exploração manual orientada ao padrão.

Como a Berghem executa

A Berghem conduz a avaliação de segurança em Open Finance a partir do papel real da instituição no ecossistema, não de uma bateria genérica sobre uma API. Começamos mapeando as interfaces expostas e consumidas, o papel no diretório de participantes e a superfície de ataque correspondente, para que o teste produza exatamente a evidência que a auditoria e o regulador esperam.

Cada engajamento combina suítes de conformidade FAPI com exploração manual de autorização, reutilização de consentimento, escalonamento de escopo, replay de token e manipulação da jornada de pagamento. O teste das APIs se apoia na nossa prática de pentest de API, enquanto a validação de mTLS e cadeia de certificados se conecta ao pentest de rede e a análise de fraude na iniciação de pagamento ao trabalho de segurança em pagamentos.

O resultado é um relatório com CVSS, prova de conceito reproduzível, impacto de negócio e roadmap de correção priorizado — servindo tanto ao time técnico quanto à conformidade. Como empresa de segurança da informação em São Paulo, alinhamos as evidências ao arcabouço de segurança cibernética do Banco Central e do CMN aplicável às instituições financeiras, incluindo as resoluções sobre segurança cibernética, e à LGPD, para que o teste alimente diretamente o programa de conformidade da instituição.

A Berghem é uma empresa de pentest brasileira, sediada em São Paulo, que executa testes de invasão manuais orientados por objetivo adversarial.

Perguntas frequentes

O que é FAPI e por que ele é obrigatório no Open Finance?

FAPI (Financial-grade API) é o perfil de segurança da OpenID Foundation adotado pelo Open Finance Brasil. Ele endurece o OAuth 2.0 com PKCE, PAR, JARM e tokens vinculados ao certificado. O teste verifica se a implementação cumpre o perfil de fato, e não apenas o declara na documentação.

Um scanner de vulnerabilidades cobre a segurança de APIs no Open Finance?

Não de forma suficiente. Um scanner identifica bibliotecas desatualizadas e configurações fracas, mas não detecta as falhas de maior impacto — autorização quebrada, consentimento sem revogação efetiva e reuso de token. Essas falhas são de lógica e só se comprovam com exploração manual orientada ao padrão.

O teste de Open Finance ajuda na conformidade regulatória?

Sim. As evidências produzidas alinham-se ao arcabouço de segurança cibernética do Banco Central e do CMN e aos princípios da LGPD sobre compartilhamento de dados pessoais. O relatório serve como insumo direto para auditorias e para demonstrar a verificação periódica de controles esperada da instituição.