Cómo una fintech en serie B corrigió 23 fallos críticos de API antes de su próxima ronda

Proyecto representativo. Detalles del cliente anonimizados y elementos específicos modificados bajo NDA.

Cambia un número en una URL y lee las transacciones bancarias de un desconocido. Eso fue lo primero que encontramos, el segundo día, en una API de fintech que mueve dinero real. El fallo siguió sin corregir durante todo el año en que un escaneo de vulnerabilidades “limpio” había estado en su carpeta de evidencias.

El cliente era una fintech en serie B, unos 40 ingenieros, a seis semanas de abrir una ronda de serie C. Su inversor principal quería una revisión de seguridad por parte de un tercero antes de firmar el term sheet. Su producto era casi por completo una API: una aplicación móvil y un panel web para socios que hablaban con el mismo conjunto de endpoints REST. Así que pidieron una prueba de penetración de API, no un escaneo de red ni un informe de casillas marcadas.

Esa distinción es toda la historia. Los problemas que encontramos eran exactamente del tipo que las herramientas automatizadas pasan por alto sin más. Al final habíamos reportado 23 problemas críticos y altos, y la gran mayoría eran fallos de autorización. La API confiaba en quien llamaba mucho más de lo que debía.

Puntos clave

• Los fallos de API más dañinos en fintech son bugs de autorización (BOLA/IDOR y autorización rota a nivel de función), no inyección ni mala configuración. Los escáneres pasan por alto casi todos.
• En este proyecto representativo reportamos 23 problemas críticos y altos en seis semanas, incluyendo exposición de datos entre cuentas, una vía de mass assignment hacia un rol de administrador y endpoints de OTP sin limitación de tasa.
• La prueba de penetración de API significa probar con varios roles de usuario reales, comparar a qué puede acceder cada token y abusar de la lógica de negocio. No es lanzar una lista de peticiones contra un único endpoint.
• Corregir la autorización a nivel de objeto (¿este usuario es dueño de este recurso?) cerró la mayoría de los críticos. La nueva prueba confirmó que las correcciones se mantenían.
• La empresa superó la due diligence técnica sin que ningún hallazgo de seguridad bloqueara la ronda.

El contexto: una API que movía dinero y confiaba en todos

El stack era conocido. Una API en Node y Express detrás de una pasarela, PostgreSQL, tokens de acceso JWT, un cliente móvil y un panel para socios. Alrededor de 180 endpoints documentados, más un puñado que no estaban en absoluto en la documentación. Siempre los hay. Los usuarios podían tener saldos, enviar transferencias, invitar a compañeros y vincular cuentas bancarias externas.

Su propia lectura del producto era que estaba “bastante sólido”. Tenían un WAF. Ejecutaban un escáner de dependencias en CI. Un proveedor anterior les había entregado un escaneo de vulnerabilidades de aspecto limpio el año anterior.

Ese escaneo es un buen ejemplo de por qué un escaneo no es un pentest. Confirmó que su configuración de TLS y las versiones de sus bibliotecas estaban bien. No decía nada sobre si el usuario A podía leer las transacciones del usuario B, que resultó ser lo único que importaba.

Nuestro enfoque: roles, tokens y a qué puede acceder cada uno

Lo planteamos como una prueba gray-box. Nos dieron la documentación de la API, una colección de Postman y varias cuentas de prueba repartidas por todos los roles: dos usuarios estándar en organizaciones distintas, un administrador de organización, un analista de solo lectura y una cuenta de panel para socios. Contar con varias cuentas por rol es la entrada más importante para una prueba de autorización real. No se puede demostrar que un usuario llega a datos a los que no debería sin los datos de un segundo usuario a los que intentar llegar.

El montaje de trabajo no tenía nada de glamuroso. Burp Suite como proxy para el tráfico móvil y el panel, con la sesión de cada cuenta guardada para poder reproducir cualquier petición con cualquier identidad. Un par de extensiones de Burp para comparar respuestas entre roles. ffuf para el descubrimiento de endpoints y parámetros. Luego, mucha edición manual de peticiones. La mayoría de los hallazgos reales salieron de leer las respuestas con atención, no de las herramientas.

La primera pasada solo mapea la superficie: cada endpoint, cada parámetro, cada formato de ID y qué rol se supone que debe llegar a él. La segunda pasada es la interesante. Tomamos una petición que pertenece legítimamente al usuario A, la reproducimos con el token del usuario B, luego con el token del analista, luego sin ningún token, y observamos qué devuelve.

Cómo era en realidad “probar la API” aquí

Tomemos el endpoint de transacciones. Aceptaba un ID de cuenta numérico en la ruta:

GET /v2/accounts/48213/transactions HTTP/1.1
Host: api.example.com
Authorization: Bearer <user-A-token>

Cambia 48213 por 48214, mantén el token del usuario A, y la API devolvía el historial completo de transacciones de otro cliente. Eso es Broken Object Level Authorization, catalogado como API1 en el OWASP API Security Top 10, y el mismo problema de fondo que la gente llama IDOR (CWE-639). Los ID eran enteros secuenciales, así que recorrer toda la base de clientes era trivial. Primer crítico registrado, el segundo día.

No fue un caso aislado. La misma falta de comprobación de propiedad apareció en los extractos, en el endpoint que devolvía los datos enmascarados de una cuenta bancaria vinculada y en una descarga de factura en PDF que tomaba un ID de documento y no hacía ninguna comprobación en absoluto. Una clase de fallo, varios endpoints. El código autenticaba el token, pero nunca preguntaba si el dueño del token realmente era dueño del objeto solicitado.

Lo que encontramos: lo más destacado

Más allá de los bugs a nivel de objeto, vale la pena señalar algunos hallazgos porque aparecen una y otra vez en las API de fintech.

Mass assignment hacia un rol de administrador. El endpoint para actualizar tu propio perfil aceptaba un cuerpo JSON y lo vinculaba directamente al modelo de usuario. Documentaba name y email. También aceptaba en silencio role. La petición de abajo ascendía a un usuario estándar a administrador de organización:

PATCH /v2/users/me HTTP/1.1
Authorization: Bearer <standard-user-token>
Content-Type: application/json

{"name":"Jordan","role":"admin"}

Eso es mass assignment (CWE-915), el fallo que el actual OWASP API Security Top 10 engloba en Broken Object Property Level Authorization. Combinado con el siguiente, se vuelve especialmente peligroso.

Autorización rota a nivel de función. Los endpoints exclusivos de administrador que listaban a todos los usuarios de la organización y cambiaban los permisos de los miembros comprobaban que estuvieras autenticado, pero no que fueras administrador. Un usuario estándar podía llamarlos directamente. Combina eso con el fallo de mass assignment y una sola cuenta con pocos privilegios tenía un camino despejado hacia el control total de una organización.

Endpoints de OTP y de restablecimiento de contraseña sin limitación de tasa. El endpoint de verificación del código de un solo uso aceptaba intentos ilimitados. Un código de seis dígitos sin bloqueo ni limitación no es un segundo factor. Es un badén. Forzamos por fuerza bruta un código válido en minutos desde una sola IP. El flujo de restablecimiento de contraseña tenía la misma brecha.

Un JWT en el que se confiaba demasiado. El token de acceso llevaba el rol del usuario y el ID de organización como claims, y al menos un servicio tomaba decisiones a partir de esos claims sin volver a comprobarlos en el servidor. Los tokens tenían una vida larga y no había revocación en el servidor, así que un token filtrado seguía siendo útil demasiado tiempo.

Nada de esto necesitó herramientas exóticas. Necesitó una segunda cuenta y alguien dispuesto a preguntarse qué pasa si envío esta petición haciéndome pasar por la persona equivocada.

El resultado

Entregamos los hallazgos sobre la marcha en lugar de volcarlo todo al final. Así es como llevamos cada proyecto con plazo acotado. Los problemas de BOLA llegaron a su equipo el segundo día para que los ingenieros pudieran empezar a corregir mientras seguíamos probando. Cada hallazgo se entregó con la petición exacta para reproducirlo, el impacto en lenguaje claro y una corrección específica.

Su equipo se movió rápido. Las correcciones fueron en su mayoría estructurales: un middleware de comprobación de propiedad que verificaba que el usuario autenticado realmente fuera dueño del objeto indicado en la ruta, comprobaciones de rol reales en cada ruta privilegiada, una allow-list de campos escribibles en lugar de vincular el cuerpo entero, y limitación de tasa más bloqueo en los endpoints de autenticación. Vidas de token más cortas y una lista de revocación resolvieron el problema del JWT.

Ejecutamos una nueva prueba completa contra las correcciones. Los 23 hallazgos críticos y altos quedaron cerrados y verificados, y el nuevo middleware de propiedad también había atrapado dos problemas de menor gravedad que habíamos señalado. Cuando la due diligence técnica del inversor se realizó unas semanas después, nada relacionado con la seguridad bloqueó la ronda. De eso se trataba: encontrarlo antes de que alguien hostil, o el auditor de un comprador, lo encuentre por ti.

Cómo ayuda CyberXplore

Esto es el núcleo de lo que hace nuestro servicio de pruebas de penetración de API: pruebas manuales y conscientes de los roles de los endpoints que de verdad hacen funcionar tu negocio, mapeadas al OWASP API Security Top 10, con pasos de reproducción que un desarrollador puede aplicar y una nueva prueba que confirma que las correcciones se mantienen. Si te diriges hacia una ronda de financiación, una integración con un socio o una fecha límite de cumplimiento y tu producto es una API, es justo cuando merece la pena. Solicita un presupuesto y cuéntanos sobre tu stack y tu calendario.

FAQ

¿Por qué un escáner de vulnerabilidades no puede encontrar estos fallos de API?

Los escáneres son buenos con los problemas conocidos: bibliotecas obsoletas, TLS débil, cabeceras ausentes, algunos patrones de inyección. Los fallos de autorización como BOLA dependen del contexto de negocio. Un escáner no tiene ni idea de que la cuenta 48214 pertenece a otro cliente, así que una respuesta 200 le parece correcta. Encontrarlos requiere a una persona que compare a qué pueden acceder distintos usuarios reales, y ese es el núcleo de la prueba de penetración de API.

¿Cuánto dura una prueba de penetración de API?

Depende del número de endpoints, del número de roles y de cuánta lógica de negocio esté implicada. Una prueba de API enfocada sobre una fintech de tamaño medio suele durar de una a tres semanas de pruebas activas más una nueva prueba. El proyecto de este artículo fue de unas dos semanas de pruebas dentro de una ventana de seis semanas que incluía la corrección y la nueva prueba.

¿Qué es BOLA y por qué es el principal riesgo de las API?

BOLA (Broken Object Level Authorization) es cuando una API comprueba que has iniciado sesión pero no que el objeto concreto que pediste te pertenece. Ocupa el primer puesto del OWASP API Security Top 10 porque es común, trivial de explotar cambiando un ID en una petición y a menudo expone los datos de todos los usuarios de golpe. Es el mismo problema de fondo que IDOR (CWE-639).

¿Hace falta acceso a producción o al código fuente?

Ninguno de los dos es estrictamente necesario, pero ambos ayudan. La mayoría de nuestros proyectos son gray-box: trabajamos contra un entorno de staging o similar a producción con varias cuentas de prueba que cubren todos los roles y acceso a la documentación de la API. El código fuente puede acelerar el análisis de causa raíz, pero los hallazgos críticos en este caso salieron de pruebas de peticiones en gray-box, no de una revisión de código.

¿Qué recibimos al final?

Un informe que empieza por el riesgo, enumera cada hallazgo con su gravedad, los pasos exactos de reproducción y una corrección concreta, además de una nueva prueba que confirma lo que realmente se cerró. Entregamos los críticos a medida que los encontramos para que tu equipo pueda empezar a remediar antes de que termine el proyecto, y estamos a mano para comentar las correcciones con tus ingenieros.

Estamos antes de una ronda. ¿Merece la pena un pentest ahora mismo?

Sí, y a menudo es el mejor momento. Los inversores realizan cada vez más una due diligence técnica, y que el auditor de un comprador encuentre un fallo de autorización crítico en la fase del term sheet es una conversación mucho peor que corregirlo con discreción de antemano. Un informe de nueva prueba limpio y verificado es una señal potente de que el equipo se toma en serio la seguridad.