Seguridad de APIs en fintechs y Open Finance: del OAuth2 al OWASP API Top 10 en la práctica

Por qué la API es la superficie de ataque crítica de una fintech

Una fintech moderna es, en la práctica, un conjunto de APIs. La app móvil, la banca por internet, los socios, las pasarelas de pago y, en Brasil, todo el ecosistema de Open Finance se comunican por HTTP/JSON. A diferencia de un sitio institucional, estas APIs exponen operaciones de movimiento financiero, consulta de saldo, datos de registro y PII regulada por la LGPD. El resultado es una superficie donde una única falla de autorización puede significar acceso a cuentas de terceros o transacciones no autorizadas.

El OWASP API Security Top 10 (edición 2023) consolidó lo que diferencia el riesgo de API del riesgo web tradicional. Las fallas dominantes dejaron de ser inyección y XSS y pasaron a ser de lógica de autorización: API1 BOLA (Broken Object Level Authorization), API2 Broken Authentication, API3 Broken Object Property Level Authorization y API5 Broken Function Level Authorization. Son fallas que los scanners genéricos rara vez detectan, porque dependen del contexto de negocio: el scanner no sabe que la cuenta 1042 no pertenece al usuario autenticado.

Para un CTO de fintech, esto cambia la estrategia de defensa. No basta con TLS, WAF y una puerta de login. El modelo de amenaza debe asumir que el atacante es un cliente autenticado legítimo que intenta acceder a recursos de otros clientes, escalar privilegios o abusar de endpoints. La norma NIST SP 800-204 (Security Strategies for Microservices) refuerza este principio: la autorización debe aplicarse lo más cerca posible del recurso, y nunca delegarse exclusivamente al gateway o al frontend.

Autenticación: OAuth2, OpenID Connect y el perfil FAPI del Open Finance Brasil

La autenticación responde a una pregunta: ¿quién está haciendo esta llamada? En las APIs de fintech el estándar de facto es OAuth2 para autorización de acceso y OpenID Connect (OIDC) para identidad. El error recurrente es tratar el access token como prueba de identidad del usuario final (no lo es) o aceptar tokens sin validar la firma, el emisor (iss), la audiencia (aud) y la expiración (exp). Los tokens opacos con introspección o los JWT firmados y validados en cada servicio son enfoques válidos; lo que no se admite es confiar en un token sin verificación criptográfica.

En el Open Finance Brasil el nivel de exigencia sube. El ecosistema adopta el perfil FAPI (Financial-grade API) 1.0 Advanced de la OpenID Foundation. En la práctica esto obliga a: PAR (Pushed Authorization Requests) para no transmitir parámetros sensibles por la URL; PKCE en el flujo de autorización; autenticación del cliente por mTLS o private_key_jwt en lugar de un client_secret simple; y sender-constrained tokens, en los que el access token queda vinculado al certificado mTLS del cliente, de modo que un token robado no funciona en otra conexión. Las respuestas y las solicitudes de consentimiento se firman (JWS), garantizando integridad de extremo a extremo.

La infraestructura de confianza del Open Finance Brasil depende del Directorio de Participantes y de certificados ICP/Brasil y del PKI del ecosistema. Las implementaciones comunes fallan al no validar correctamente la cadena de certificados, al aceptar tokens con un alcance (scope) más amplio que el consentimiento otorgado, o al no vincular el consentimiento (consent_id) a la transacción efectivamente ejecutada. Cada uno de estos puntos es un vector de autorización indebida disfrazado de problema de autenticación.

Recomendaciones concretas: access tokens de vida corta con refresh tokens rotados; nunca aceptar el algoritmo none en JWT; fijar la allowlist de algoritmos de firma en el servidor; y validar aud para que un token emitido para un servicio no sea aceptado por otro. Para el usuario final, MFA resistente a phishing (WebAuthn/FIDO2) en el flujo de autorización reduce drásticamente el secuestro de sesión.

Autorización y BOLA/IDOR: la falla que más derriba fintechs

BOLA, también conocida como IDOR (Insecure Direct Object Reference), ocurre cuando la API expone un identificador de objeto (una cuenta, un pago, un documento) y no verifica si el token autenticado tiene derecho sobre ese objeto específico. Un endpoint como GET /v1/accounts/{accountId}/transactions que solo comprueba si hay un token válido, pero no si ese token pertenece al dueño de accountId, permite que cualquier cliente lea los datos de cualquier cuenta con solo cambiar el ID. Es la falla API1 del OWASP y la campeona de impacto en fintech.

La defensa es arquitectónica y disciplinada. La verificación de propiedad del objeto debe ocurrir en la capa de servicio, junto a la consulta de datos, y derivarse del token, nunca de un parámetro controlado por el cliente. No confíe en IDs secuenciales como control de seguridad (los UUID no sustituyen la verificación de autorización, solo dificultan la enumeración). Centralice la decisión de acceso en un motor de políticas (ABAC/ReBAC, por ejemplo con OPA/Rego) para evitar que cada desarrollador reimplemente la regla de forma inconsistente.

BOLA tiene hermanas igualmente peligrosas. API3 (Broken Object Property Level Authorization) incluye mass assignment, cuando el cliente envía campos extra en el cuerpo (por ejemplo role o balance) que se persisten sin validación, y excessive data exposure, cuando la API devuelve el objeto entero y deja que el frontend filtre. Use DTOs explícitos de entrada y de salida: acepte solo los campos esperados y serialice solo los campos autorizados. API5 (Broken Function Level Authorization) cubre el acceso a funciones administrativas por usuarios comunes, común cuando las rutas /admin dependen solo de la oscuridad.

Este es exactamente el tipo de falla que un pentest de API encuentra y un scanner automatizado no. Validar la autorización por objeto exige entender el modelo de negocio, crear dos usuarios legítimos e intentar, con el token de uno, acceder a los recursos del otro en cada endpoint. Es un trabajo de seguridad ofensiva orientado al contexto.

Rate limiting, validación de entradas y secrets

API4 (Unrestricted Resource Consumption) trata sobre el abuso de recursos: los endpoints sin límite permiten fuerza bruta de credenciales y OTP, scraping de datos, fraude por intento y denegación de servicio. Aplique rate limiting por cliente autenticado, por IP y por endpoint sensible, con límites diferenciados para operaciones de escritura y de lectura. En flujos de pago y autenticación, combine el throttling con bloqueo progresivo y detección de anomalías. Limite también el tamaño del payload, la profundidad de los objetos JSON y la paginación máxima para contener el consumo de CPU y memoria.

La validación de entradas es la base contra la inyección y la corrupción de datos. Adopte allowlist por schema: valide cada request contra un contrato OpenAPI/JSON Schema en el borde, rechazando lo que no coincide, en lugar de intentar limpiar entradas maliciosas. Use siempre consultas parametrizadas en la base de datos y bibliotecas que traten el tipo de dato esperado. API8 (Security Misconfiguration) recuerda que un CORS permisivo, mensajes de error verbosos con stack trace, métodos HTTP no usados habilitados y headers de seguridad ausentes amplían la superficie sin necesidad.

La gestión de secrets es donde muchas startups acumulan deuda. Las claves de API, las credenciales de base de datos, los certificados mTLS y las claves de firma JWT no pueden vivir en el repositorio, en variables de entorno versionadas ni en logs. Use una bóveda (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) con rotación automática y acceso por identidad de workload, alineada a las directrices del NIST SP 800-57 para la gestión de claves. Habilite el secret scanning en el CI para frenar filtraciones antes del merge, y trate cualquier secret expuesto como comprometido: rótelo, no solo lo elimine del historial.

Logging, observabilidad y detección sin filtrar datos

API9 (Improper Inventory Management) y API10 (Unsafe Consumption of APIs) apuntan a dos puntos ciegos: no se defiende lo que no se conoce, y confiar ciegamente en APIs de terceros propaga el riesgo. Mantenga un inventario vivo de todas las APIs, versiones y entornos, marcando los endpoints obsoletos (shadow y zombie APIs) que siguen en el aire sin mantenimiento. Para las integraciones de terceros y socios del Open Finance, valide las respuestas con el mismo rigor que las entradas y no siga redirecciones a ciegas.

El logging es un control de seguridad y un requisito de auditoría, pero debe hacerse con cuidado. Registre eventos de autenticación, autorización denegada, cambios de consentimiento y operaciones financieras con identificadores correlacionables (trace/correlation ID), preservando la capacidad de reconstruir una sesión durante una investigación. Al mismo tiempo, nunca registre tokens, contraseñas, PAN completo, claves Pix ni PII en texto plano: aplique masking y redacción en el origen. El NIST SP 800-92 (Guide to Computer Security Log Management) y los principios de minimización de la LGPD orientan ese equilibrio.

La detección depende de logs estructurados y centralizados que alimenten un SIEM con reglas para los patrones de ataque a API: picos de 401/403, intentos secuenciales de IDs (firma de BOLA), uso de token fuera del binding mTLS y desvíos de volumen por cliente. Las métricas de latencia y error por endpoint también anticipan el abuso. El objetivo es reducir el tiempo entre el compromiso y la detección, métrica que define el impacto real de un incidente.

Cómo Decripte ayuda a cerrar el ciclo

Una política de seguridad solo se vuelve garantía cuando se prueba bajo ataque. Decripte actúa en el frente ofensivo: pentest de APIs con foco en lo que importa para una fintech, BOLA/IDOR endpoint por endpoint, fallas de autorización funcional, validación de los flujos OAuth2/OIDC y conformidad práctica con el perfil FAPI del Open Finance Brasil. En lugar de un informe genérico de scanner, la entrega es la prueba de que un cliente autenticado no logra cruzar la frontera de los datos de otro.

Encontrar la falla es la mitad del trabajo. Con la gestión de vulnerabilidades de Decripte, los hallazgos entran en un ciclo continuo de priorización por riesgo real, seguimiento de la corrección y retest, integrado al flujo de ingeniería. Esto evita que el pentest se convierta en un PDF olvidado y mantiene la postura de seguridad al ritmo de despliegue de una startup.

Para los equipos que están empezando a estructurar la seguridad, Decripte ofrece un plan gratuito, un punto de entrada para mapear la superficie de APIs y ganar visibilidad sin barrera inicial. A medida que la fintech crece y el alcance regulatorio se estrecha, la alianza evoluciona del diagnóstico a la validación ofensiva recurrente y la gestión continua del riesgo.

Checklist práctico

1. 1

   1. Inventaríe y contractualice sus APIs

   Liste todas las APIs, versiones y entornos; documente cada endpoint en un contrato OpenAPI y elimine las shadow/zombie APIs que están en el aire sin mantenimiento.

2. 2

   2. Estandarice la autenticación fuerte

   Use OAuth2/OIDC con validación completa de firma, iss, aud y exp; en el Open Finance, implemente FAPI 1.0 Advanced (PAR, PKCE, mTLS o private_key_jwt, sender-constrained tokens).

3. 3

   3. Aplique autorización por objeto

   En todo endpoint que reciba un ID, verifique en la capa de servicio si el token autenticado es dueño del recurso; centralice las reglas en un motor de políticas para evitar BOLA/IDOR.

4. 4

   4. Controle la entrada y la salida de datos

   Valide cada request contra JSON Schema, use DTOs explícitos para bloquear el mass assignment y exponga solo los campos autorizados en la respuesta.

5. 5

   5. Limite el consumo y proteja los secrets

   Configure rate limiting por cliente y endpoint, limite el tamaño del payload y almacene claves y certificados en una bóveda con rotación automática; active el secret scanning en el CI.

6. 6

   6. Registre y monitoree con seguridad

   Centralice logs estructurados con correlation ID, enmascare la PII y los secrets en el origen y cree alertas en el SIEM para picos de 403, enumeración de IDs y uso de token fuera del binding.

7. 7

   7. Pruebe bajo ataque e itere

   Realice un pentest de API enfocado en la autorización y los flujos OAuth2/FAPI, alimente la gestión de vulnerabilidades con los hallazgos y haga retest después de cada corrección.

Preguntas frecuentes