API Security for Fintechs and Open Finance: from OAuth2 to the OWASP API Top 10 in Practice

Why the API is a fintech's critical attack surface

A modern fintech is, in practice, a collection of APIs. The mobile app, internet banking, partners, payment gateways and, in Brazil, the entire Open Finance ecosystem all communicate over HTTP/JSON. Unlike a marketing website, these APIs expose financial movement operations, balance queries, account data, and PII regulated by the LGPD. The result is a surface where a single authorization flaw can mean access to third-party accounts or unauthorized transactions.

The OWASP API Security Top 10 (2023 edition) consolidated what distinguishes API risk from traditional web risk. The dominant flaws are no longer injection and XSS but authorization-logic failures: API1 BOLA (Broken Object Level Authorization), API2 Broken Authentication, API3 Broken Object Property Level Authorization, and API5 Broken Function Level Authorization. These are flaws that generic scanners rarely detect, because they depend on business context: the scanner does not know that account 1042 does not belong to the authenticated user.

For a fintech CTO, that changes the defense strategy. TLS, a WAF, and a login gate are not enough. The threat model must assume the attacker is a legitimate authenticated client trying to access other clients' resources, escalate privileges, or abuse endpoints. NIST SP 800-204 (Security Strategies for Microservices) reinforces this principle: authorization must be enforced as close as possible to the resource, and never delegated exclusively to the gateway or the frontend.

Authentication: OAuth2, OpenID Connect, and the FAPI profile of Open Finance Brasil

Authentication answers one question: who is making this call? In fintech APIs the de facto standard is OAuth2 for access authorization and OpenID Connect (OIDC) for identity. The recurring mistake is treating the access token as proof of the end user's identity (it is not) or accepting tokens without validating signature, issuer (iss), audience (aud), and expiration (exp). Opaque tokens with introspection or JWTs signed and validated at each service are both valid approaches; what is never acceptable is trusting a token without cryptographic verification.

In Open Finance Brasil the bar rises. The ecosystem adopts the FAPI (Financial-grade API) 1.0 Advanced profile from the OpenID Foundation. In practice this requires: PAR (Pushed Authorization Requests) so sensitive parameters do not travel in the URL; PKCE in the authorization flow; client authentication via mTLS or private_key_jwt instead of a simple client_secret; and sender-constrained tokens, in which the access token is bound to the client's mTLS certificate so a stolen token does not work on another connection. Consent responses and requests are signed (JWS), guaranteeing end-to-end integrity.

The Open Finance Brasil trust infrastructure relies on the Participant Directory and on ICP-Brasil certificates and the ecosystem's PKI. Common implementations fail by not validating the certificate chain correctly, by accepting tokens with a scope broader than the granted consent, or by not binding the consent (consent_id) to the transaction actually executed. Each of these is a vector for improper authorization disguised as an authentication problem.

Concrete recommendations: short-lived access tokens with rotated refresh tokens; never accept the none algorithm in a JWT; pin the allowlist of signature algorithms on the server; and validate aud so a token issued for one service is not accepted by another. For the end user, phishing-resistant MFA (WebAuthn/FIDO2) in the authorization flow drastically reduces session hijacking.

Authorization and BOLA/IDOR: the flaw that most often takes down fintechs

BOLA, also known as IDOR (Insecure Direct Object Reference), occurs when the API exposes an object identifier (an account, a payment, a document) and does not verify that the authenticated token has rights over that specific object. An endpoint like GET /v1/accounts/{accountId}/transactions that only checks whether there is a valid token, but not whether that token belongs to the owner of accountId, lets any client read any account's data just by changing the ID. It is the OWASP API1 flaw and the top impact driver in fintech.

The defense is architectural and disciplined. Object-ownership verification must happen at the service layer, alongside the data query, and be derived from the token, never from a client-controlled parameter. Do not rely on sequential IDs as a security control (UUIDs do not replace an authorization check, they only make enumeration harder). Centralize the access decision in a policy engine (ABAC/ReBAC, for example with OPA/Rego) so each developer does not reimplement the rule inconsistently.

BOLA has equally dangerous siblings. API3 (Broken Object Property Level Authorization) includes mass assignment, when the client sends extra fields in the body (for example role or balance) that are persisted without validation, and excessive data exposure, when the API returns the whole object and lets the frontend filter it. Use explicit input and output DTOs: accept only the expected fields and serialize only the authorized ones. API5 (Broken Function Level Authorization) covers ordinary users accessing administrative functions, common when /admin routes rely on obscurity alone.

This is exactly the kind of flaw an API pentest finds and an automated scanner does not. Validating object-level authorization requires understanding the business model, creating two legitimate users, and trying, with one's token, to access the other's resources at every endpoint. It is context-driven offensive security work.

Rate limiting, input validation, and secrets

API4 (Unrestricted Resource Consumption) is about resource abuse: endpoints without limits enable credential and OTP brute force, data scraping, trial-based fraud, and denial of service. Apply rate limiting per authenticated client, per IP, and per sensitive endpoint, with different limits for write and read operations. In payment and authentication flows, combine throttling with progressive lockout and anomaly detection. Also limit payload size, JSON object depth, and maximum pagination to contain CPU and memory consumption.

Input validation is the foundation against injection and data corruption. Adopt a schema-based allowlist: validate each request against an OpenAPI/JSON Schema contract at the edge, rejecting whatever does not match, rather than trying to sanitize malicious input. Always use parameterized queries at the database and libraries that handle the expected data type. API8 (Security Misconfiguration) reminds us that permissive CORS, verbose error messages with stack traces, unused HTTP methods left enabled, and missing security headers expand the surface needlessly.

Secrets management is where many startups accumulate debt. API keys, database credentials, mTLS certificates, and JWT signing keys cannot live in a repository, in versioned environment variables, or in logs. Use a vault (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) with automatic rotation and workload-identity access, aligned with the NIST SP 800-57 guidelines for key management. Enable secret scanning in CI to block leaks before merge, and treat any exposed secret as compromised: rotate it, do not just remove it from history.

Logging, observability, and detection without leaking data

API9 (Improper Inventory Management) and API10 (Unsafe Consumption of APIs) point to two blind spots: you cannot defend what you do not know, and blindly trusting third-party APIs propagates risk. Keep a living inventory of all APIs, versions, and environments, flagging obsolete endpoints (shadow and zombie APIs) that stay online without maintenance. For third-party and Open Finance partner integrations, validate responses as rigorously as inputs and do not follow redirects blindly.

Logging is both a security control and an audit requirement, but it must be done carefully. Record authentication events, denied authorizations, consent changes, and financial operations with correlatable identifiers (trace/correlation ID), preserving the ability to reconstruct a session during an investigation. At the same time, never log tokens, passwords, full PAN, Pix keys, or PII in clear text: apply masking and redaction at the source. NIST SP 800-92 (Guide to Computer Security Log Management) and the LGPD's minimization principles guide this balance.

Detection depends on structured, centralized logs feeding a SIEM with rules for API attack patterns: spikes in 401/403, sequential ID attempts (the signature of BOLA), token use outside the mTLS binding, and per-client volume deviation. Latency and error metrics per endpoint also flag abuse early. The goal is to shorten the time between compromise and detection, the metric that defines an incident's real impact.

How Decripte helps close the loop

A security policy only becomes assurance when it is tested under attack. Decripte works on the offensive edge: API pentesting focused on what matters for a fintech, BOLA/IDOR endpoint by endpoint, functional authorization flaws, validation of OAuth2/OIDC flows, and practical conformance with the FAPI profile of Open Finance Brasil. Instead of a generic scanner report, the deliverable is proof that an authenticated client cannot cross the boundary into another's data.

Finding the flaw is half the work. With Decripte's vulnerability management, findings enter a continuous cycle of prioritization by real risk, remediation tracking, and retesting, integrated into the engineering workflow. This keeps the pentest from becoming a forgotten PDF and keeps the security posture in step with a startup's deployment cadence.

For teams just starting to structure security, Decripte offers a free plan, an entry point to map the API surface and gain visibility with no upfront barrier. As the fintech grows and the regulatory scope tightens, the partnership evolves from assessment to recurring offensive validation and continuous risk management.

Practical checklist

1. 1

   1. Inventory and contract your APIs

   List all APIs, versions, and environments; document every endpoint in an OpenAPI contract and eliminate shadow/zombie APIs that are online without maintenance.

2. 2

   2. Standardize strong authentication

   Use OAuth2/OIDC with full validation of signature, iss, aud, and exp; in Open Finance, implement FAPI 1.0 Advanced (PAR, PKCE, mTLS or private_key_jwt, sender-constrained tokens).

3. 3

   3. Enforce object-level authorization

   On every endpoint that receives an ID, verify at the service layer that the authenticated token owns the resource; centralize the rules in a policy engine to prevent BOLA/IDOR.

4. 4

   4. Control data input and output

   Validate each request against a JSON Schema, use explicit DTOs to block mass assignment, and expose only the authorized fields in the response.

5. 5

   5. Limit consumption and protect secrets

   Configure rate limiting per client and endpoint, limit payload size, and store keys and certificates in a vault with automatic rotation; enable secret scanning in CI.

6. 6

   6. Log and monitor securely

   Centralize structured logs with a correlation ID, mask PII and secrets at the source, and create SIEM alerts for 403 spikes, ID enumeration, and token use outside the binding.

7. 7

   7. Test under attack and iterate

   Run an API pentest focused on authorization and OAuth2/FAPI flows, feed the findings into vulnerability management, and retest after each fix.

Frequently asked questions