Una configuración incorrecta en una API puede parecer un problema menor hasta que permite consultar información personal sin autenticación y, peor aún, enumerar una base completa de clientes.

Desde Neural Code AI, reportamos recientemente un hallazgo de este tipo a través del programa de Vulnerability Disclosure de una aerolínea.

La divulgación coordinada continúa en curso, por lo que no identificaremos a la empresa afectada ni compartiremos información que permita reproducir el hallazgo sobre sus sistemas. Sin embargo, el caso permite mostrar un problema que muchas organizaciones deberían revisar: la exposición de datos personales a través de APIs mal configuradas.

Dos vías distintas para acceder a información personal

La plataforma de e-commerce presentaba dos problemas independientes, ambos accesibles sin iniciar sesión, sin cookies y sin utilizar un token de autenticación.

El primero estaba relacionado con una API de data entities, utilizando un patrón similar a MasterData.

Dentro de la configuración existían siete campos definidos como públicos por error. Entre ellos se encontraban información como:

1. Nombre.
2. Apellido.
3. Teléfono.
4. RUT.
5. Otros datos asociados al perfil del cliente.

Al realizar una consulta utilizando un correo electrónico de prueba, la API devolvía la información personal asociada a ese registro.

Esto significaba que determinados datos que debían encontrarse protegidos podían ser consultados por un usuario no autenticado.

¿Cómo comprobamos que realmente existía una exposición?

En una auditoría de seguridad no basta con obtener una respuesta inesperada. También es necesario descartar falsos positivos y entender exactamente dónde se encuentra el problema.

Por esa razón se realizaron distintas validaciones utilizando exclusivamente cuentas y datos de prueba propios.

Primero, se consultó un correo electrónico de prueba y la API respondió correctamente con un código 200, incluyendo información asociada al registro.

Posteriormente se realizó la misma consulta utilizando un correo inexistente.

En ese caso, la respuesta fue un arreglo vacío.

Esto permitió confirmar que el endpoint estaba realizando una búsqueda real sobre los registros almacenados y no entregando información genérica.

Luego se solicitaron campos que sí se encontraban configurados como privados, como correo electrónico, documento y fecha de nacimiento.

La respuesta cambió:

403 Forbidden

con el mensaje:

Cannot read private fields

Esta diferencia fue especialmente relevante.

El sistema sí distinguía entre campos públicos y privados. El problema era que varios datos sensibles habían quedado configurados como públicos cuando no correspondía.

El segundo problema aumentaba considerablemente el impacto

Durante la revisión apareció un segundo endpoint con un comportamiento más delicado.

Este permitía realizar búsquedas utilizando patrones con comodines.

En términos simples, ya no era necesario conocer previamente el correo electrónico de un cliente para encontrar registros.

El endpoint podía devolver conjuntos de resultados a partir de búsquedas amplias, permitiendo avanzar progresivamente sobre la información almacenada.

Además, una cabecera de la propia API, REST-Content-Range, permitía conocer la cantidad total de registros disponibles.

La combinación de ambos comportamientos elevaba significativamente el riesgo:

datos personales expuestos + consultas amplias + ausencia de autenticación.

¿Cómo se llegó al hallazgo?

La investigación comenzó revisando el frontend de la aplicación y algunos source maps que se encontraban expuestos públicamente.

Estos archivos permitieron identificar referencias al nombre de la entidad utilizada para almacenar clientes y parte de la estructura empleada por las APIs.

A partir de esa información se realizaron pruebas controladas utilizando únicamente información propia.

El análisis permitió identificar primero la exposición de determinados campos y posteriormente el endpoint que aceptaba búsquedas demasiado amplias.

Este tipo de situaciones demuestra por qué una auditoría no debería limitarse únicamente a revisar formularios o vulnerabilidades tradicionales.

Muchas veces el problema se encuentra en la forma en que se diseñaron o configuraron las APIs que conectan los distintos componentes de una aplicación.

Impacto del hallazgo

El impacto principal era sobre la confidencialidad de los datos personales.

Una persona sin autenticación podía potencialmente acceder a información de clientes y realizar consultas a escala sin necesitar privilegios dentro de la plataforma.

El hallazgo fue clasificado como:

CVSS 3.1: 7.5 — High

La vulnerabilidad fue reportada mediante divulgación responsable y toda la evidencia utilizada durante la investigación correspondió exclusivamente a cuentas y datos de prueba propios.

Un problema técnico que también afecta la protección de datos

Este tipo de hallazgos cobra especial relevancia en Chile con la Ley 21.719, que eleva las exigencias relacionadas con el tratamiento y protección de datos personales.

Las empresas no solo deben preocuparse de almacenar correctamente la información.

También deben conocer:

• Qué sistemas tienen acceso a esos datos.
• Qué APIs los exponen.
• Qué usuarios pueden consultarlos.
• Qué campos se encuentran disponibles públicamente.
• Qué controles de autenticación y autorización existen.
• Qué registros de actividad y trazabilidad mantiene la organización.

Una fuga de información no necesariamente requiere un ataque extremadamente sofisticado.

Una API mal configurada, un endpoint antiguo o un control de acceso incompleto puede ser suficiente para generar una exposición relevante.

Qué deberían revisar las empresas

Las organizaciones que procesan información personal deberían incorporar la revisión de APIs dentro de sus evaluaciones de seguridad.

Algunos puntos importantes son:

• Identificar qué endpoints procesan datos personales.
• Revisar qué campos están definidos como públicos o privados.
• Evitar búsquedas excesivamente amplias mediante comodines o filtros vacíos.
• Exigir autenticación cuando corresponda.
• Validar que cada usuario pueda acceder únicamente a los registros autorizados.
• Revisar APIs antiguas o endpoints que siguen activos aunque ya no formen parte del flujo principal.
• Mantener trazabilidad sobre los accesos a información sensible.

La seguridad de los datos no depende únicamente de la base de datos donde se almacenan. También depende de cada servicio, integración y API que pueda acceder a ellos.

Auditorías de seguridad y preparación para la Ley 21.719

En Neural Code AI realizamos auditorías técnicas orientadas a identificar este tipo de riesgos antes de que se conviertan en incidentes.

Nuestros servicios pueden incluir revisión de:

• Aplicaciones web.
• APIs.
• Infraestructura.
• Controles de autenticación y autorización.
• Exposición de información sensible.
• Configuraciones de seguridad.
• Superficie de ataque.
• Tratamiento técnico de datos personales.

Si tu empresa procesa RUT, correos electrónicos, teléfonos, información de trabajadores, clientes o proveedores, revisar cómo esos datos están siendo expuestos por tus sistemas ya no debería considerarse únicamente una tarea de ciberseguridad.

También forma parte de una estrategia adecuada de protección de datos.

Detectar una exposición durante una auditoría siempre será mejor que descubrirla después de un incidente.

En Neural Code AI podemos ayudarte a evaluar la seguridad de tus sistemas, aplicaciones y APIs, e identificar brechas técnicas que puedan afectar la protección de datos personales de tu organización.