En muchas aplicaciones modernas, especialmente aquellas construidas sobre arquitecturas serverless, una parte importante de la seguridad depende de que cada capa valide correctamente quién puede acceder a qué información.

Cuando esa validación queda delegada al frontend o se asume que “si la aplicación lo solicita, entonces el usuario tiene permiso”, el impacto puede ser grave.

Durante una evaluación de seguridad realizada sobre una plataforma fintech de activos digitales, identificamos una combinación de fallas que permitía acceder a información personal y financiera de otros usuarios sin una autenticación válida y, en ciertos escenarios, modificar registros que no pertenecían al usuario que realizaba la solicitud.

El hallazgo fue reportado mediante divulgación coordinada y actualmente el proceso sigue en curso. Por esa razón, el nombre de la empresa, sus dominios y los identificadores reales se mantienen reservados. Todas las pruebas fueron realizadas utilizando datos propios y sin alterar información de terceros.

El problema no estaba en una sola vulnerabilidad

La plataforma combinaba un frontend moderno con autenticación federada, una base de datos documental en la nube y distintos endpoints REST utilizados para consultar información de negocio.

La raíz del problema estaba en la autorización.

Por una parte, varias reglas de Firestore permitían lecturas y, en algunos casos, escrituras sin verificar correctamente que el usuario autenticado fuera realmente el propietario del documento solicitado.

Por otra, distintos endpoints REST recibían un identificador de usuario como parámetro y devolvían información asociada a ese identificador sin comprobar que correspondiera al usuario autenticado.

Ese patrón corresponde a una falla de autorización a nivel de objeto, conocida comúnmente como IDOR o BOLA.

En términos simples, el backend confiaba demasiado en los datos enviados por el cliente.

Qué información podía quedar expuesta

La información accesible incluía datos de identidad, información financiera, historial de movimientos y, en el caso más delicado, datos completos de tarjetas.

Entre los datos observados se encontraban:

• Nombre y apellido.
• Identificador fiscal.
• Correo electrónico.
• Saldos asociados a cuentas.
• Historial de transacciones.
• Número de tarjeta.
• CVV/CVC.
• Fecha de vencimiento.
• Nombre del titular.

La posibilidad de correlacionar toda esa información por usuario permitía construir un perfil financiero completo de un cliente.

El punto más crítico era la exposición del PAN completo junto con CVV y vencimiento. Esa combinación puede ser suficiente para realizar transacciones no presenciales y eleva considerablemente el impacto de una vulnerabilidad de este tipo.

El frontend entregaba demasiadas pistas

El descubrimiento comenzó revisando los bundles y source maps que se encontraban expuestos públicamente desde el frontend.

Estos archivos permitieron identificar referencias a la configuración utilizada por la aplicación, nombres de colecciones y rutas de negocio implementadas por el backend.

Es importante aclarar que determinados valores presentes en aplicaciones frontend, como una API key web de Firebase, pueden ser públicos por diseño.

El problema aparece cuando esa información pública termina siendo suficiente para acceder a recursos sensibles porque las reglas del backend no están correctamente configuradas.

Una clave pública nunca debería reemplazar un control de autorización.

Una base de datos documental con reglas demasiado permisivas

Durante la revisión se observó que determinadas colecciones podían ser consultadas sin una validación adecuada de identidad.

En una configuración correcta, una solicitud sobre información sensible debería verificar al menos dos cosas:

que exista una sesión válida y que el usuario autenticado sea realmente el propietario del documento solicitado.

Cuando esa segunda condición falta, conocer o enumerar identificadores de usuario puede convertirse en una vía directa para consultar información de terceros.

Este problema se agravaba porque también era posible obtener múltiples identificadores reales a partir de relaciones existentes dentro de la propia aplicación.

El mismo problema se repetía en las APIs de negocio

La base de datos no era el único componente afectado.

Distintos endpoints relacionados con saldos, movimientos y tarjetas aceptaban un identificador de usuario enviado directamente por el cliente.

El servidor utilizaba ese valor para determinar qué información debía entregar, pero no verificaba que perteneciera al usuario autenticado.

Ese detalle cambia por completo el modelo de seguridad.

En lugar de que el servidor diga:

“este token pertenece al usuario A, por lo tanto solo puede consultar información de A”,

el comportamiento se acercaba más a:

“el cliente dice que quiere consultar al usuario B, entonces le entregamos la información de B”.

Ese es exactamente el tipo de confianza que un backend nunca debería depositar en el cliente.

El hallazgo más crítico: datos completos de tarjeta

Uno de los endpoints devolvía información completa de tarjetas asociadas a un usuario.

No se trataba únicamente de los últimos cuatro dígitos.

La respuesta podía incluir el número completo de la tarjeta, el código CVV/CVC, la fecha de vencimiento y el nombre del titular.

Ese conjunto de información es especialmente sensible porque puede ser utilizado en escenarios de fraude card-not-present.

Desde una perspectiva de seguridad y cumplimiento, la presencia del CVV en este tipo de respuesta constituye además un problema particularmente serio.

El artículo técnico original clasifica esta exposición como uno de los componentes que convierten el hallazgo en crítico.

No solo estaba comprometida la confidencialidad

La evaluación también permitió confirmar que determinadas reglas admitían escritura sobre documentos pertenecientes a otros usuarios.

Para validar ese comportamiento se utilizó una prueba no destructiva, limitada a un campo de sondeo inocuo y sin modificar información legítima de clientes.

La diferencia entre una respuesta permitida y un bloqueo por permisos fue suficiente para demostrar que existía un problema de integridad.

En términos de riesgo, esto significa que la vulnerabilidad no se limitaba a leer información.

También existía la posibilidad conceptual de alterar determinados registros ajenos.

No se realizaron acciones sobre datos reales de terceros.

CVSS 3.1: 9.1 Critical

El vector principal del hallazgo fue clasificado como:

AV:N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:N

CVSS 3.1: 9.1 — Critical

La severidad se explica por una combinación especialmente delicada:

• Explotación remota.
• Baja complejidad.
• Sin privilegios.
• Sin interacción del usuario.
• Alto impacto sobre la confidencialidad.
• Alto impacto sobre la integridad.

Si se considerara únicamente la exposición de información, sin el vector de escritura, la severidad bajaría a 7.5 High.

Es la combinación de fuga de datos y modificación entre usuarios la que eleva el caso a crítico.

Por qué este tipo de fallas sigue apareciendo

Las arquitecturas serverless han simplificado enormemente el desarrollo de aplicaciones, pero también distribuyen la lógica de seguridad entre varias capas.

Parte del control puede estar en:

• El frontend.
• Las reglas de la base de datos.
• Las funciones serverless.
• Las APIs.
• Los tokens de autenticación.
• Los servicios externos.

Cuando la autorización no se diseña de forma consistente entre todas esas capas, aparecen brechas.

Una aplicación puede tener una interfaz que aparentemente impide acceder a datos ajenos, pero eso no significa que el backend esté aplicando la misma restricción.

La interfaz nunca debe ser considerada un control de seguridad.

Qué deberían revisar los equipos técnicos

La principal recomendación es sencilla:

la autorización debe verificarse en el servidor, siempre.

Cada solicitud que acceda a información asociada a un usuario debería validar que el objeto solicitado pertenece realmente a la identidad autenticada.

También es importante:

• Configurar las reglas de Firestore con una política de denegación por defecto.
• Validar explícitamente la propiedad de cada documento.
• No confiar en identificadores enviados libremente por el cliente.
• Derivar la identidad desde un token autenticado y verificado.
• Mantener datos sensibles detrás de controles específicos.
• Auditar accesos a información financiera.
• Revisar endpoints antiguos o poco utilizados.
• Evitar publicar source maps de producción cuando no sean necesarios.

Estas recomendaciones coinciden con las medidas planteadas en el análisis técnico del hallazgo.

La seguridad de una fintech no termina en el login

Uno de los errores más frecuentes es asumir que una aplicación es segura porque cuenta con autenticación.

Autenticar significa saber quién es el usuario.

Autorizar significa decidir qué puede hacer ese usuario.

Son problemas distintos.

Una aplicación puede tener un login perfectamente implementado y aun así permitir que un usuario consulte o modifique información perteneciente a otros clientes.

Por eso las pruebas de seguridad deben incluir revisión de autorización a nivel de objeto, reglas de bases de datos, APIs, relaciones entre recursos y controles de acceso reales en el backend.

Auditorías de seguridad para aplicaciones, APIs y fintech

En Neural Code AI realizamos auditorías técnicas orientadas a identificar este tipo de vulnerabilidades antes de que sean explotadas.

Nuestras evaluaciones pueden incluir:

• Seguridad de aplicaciones web.
• Revisión de APIs.
• Pruebas de autorización IDOR/BOLA.
• Revisión de configuraciones cloud.
• Evaluación de reglas de Firestore.
• Exposición de información sensible.
• Controles de autenticación y autorización.
• Análisis de superficie de ataque.
• Revisión de datos financieros y personales expuestos.
• Pruebas de seguridad sobre arquitecturas serverless.

Este tipo de auditoría es especialmente importante para fintech, plataformas SaaS y organizaciones que procesan datos financieros, información personal o activos digitales.

La mayoría de estas fugas no nace de un exploit extremadamente sofisticado.

Muchas veces comienza con una suposición incorrecta:

“si la aplicación lo solicita, entonces el usuario debe tener permiso”.

La autorización nunca debería depender de esa suposición.

El backend debe comprobarla.

Divulgación coordinada en curso. Publicado por el equipo de investigación de Neural Code AI.