Recientemente se detectó un comportamiento preocupante en una aplicación web para el registro de líneas celulares, donde al ingresar un número de teléfono móvil como parte de un proceso de validación por SMS (OTP – One Time Password), el backend devolvía en la respuesta información personal del titular de la línea.
Aunque estos datos no eran visibles en la interfaz de usuario, sí podían observarse fácilmente desde las herramientas de desarrollo del navegador.
Este tipo de incidentes, incluso cuando son corregidos rápidamente, dejan una lección clara: la seguridad no debe validarse únicamente desde la experiencia visual del usuario, sino desde el comportamiento real de la aplicación y sus APIs.
¿Qué ocurrió técnicamente?
Durante el flujo de registro/autenticación de la línea celular:
- El frontend realizaba una llamada a un endpoint backend.
- La respuesta incluía un objeto con datos personales como:
- Nombre y apellidos
- Identificadores internos de cliente
- Fecha de nacimiento
- CURP, RFC y correo electrónico (en algunos casos)
- Esta información se entregaba antes de que el usuario completara la autenticación mediante el número de confirmación (OTP) que se envía por SMS.
Aunque la aplicación fue corregida posteriormente (sanitizando la respuesta o moviendo la consulta de datos a una fase autenticada), el incidente evidencia un problema clásico de seguridad en aplicaciones modernas: exposición excesiva de datos (Overexposed Data / Broken Object Level Authorization).
¿Por qué este tipo de fallas pasan desapercibidas?
Porque muchas organizaciones validan la seguridad solo desde:
- Pruebas funcionales
- Pruebas manuales de UI
- Validaciones de negocio
Pero no inspeccionan el tráfico real, ni cómo se comportan las APIs frente a entradas válidas pero no autenticadas.
Aquí es donde realizar pruebas de seguridad como DAST y SAST juegan un papel crítico.
El rol clave de SAST (Static Application Security Testing)
SAST permite analizar el código fuente antes de que la aplicación llegue a producción y detectar:
- Métodos que retornan objetos completos cuando solo deberían devolver identificadores
- Falta de controles de autorización a nivel de lógica
- Uso incorrecto de modelos de datos (DTOs mal definidos)
- Dependencias inseguras o configuraciones débiles
En este caso, un análisis SAST pudo haber detectado que:
- El endpoint exponía campos sensibles innecesarios
- No existía una validación de contexto de autenticación previa a la respuesta
El valor de DAST (Dynamic Application Security Testing)
DAST simula el comportamiento real de un atacante o usuario curioso, interactuando con la aplicación ya desplegada.
Con DAST se habría detectado fácilmente que:
- Al ingresar un número telefónico válido, la API devolvía datos personales
- No se requería autenticación previa
- El endpoint era accesible sin controles adicionales
- Los datos viajaban completos en la respuesta
Este tipo de hallazgos son comunes en pruebas DAST bien ejecutadas sobre APIs REST, especialmente en flujos de registro y autenticación.
Implicaciones legales bajo la LFPDPPP
Desde la perspectiva de la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP), este incidente es relevante porque:
- Los datos personales eran tratados y transmitidos sin una finalidad clara para el usuario en ese momento
- Se exponían más datos de los estrictamente necesarios (principio de proporcionalidad)
- No existía una barrera efectiva para evitar el acceso no autorizado (principio de seguridad)
La LFPDPPP establece que las organizaciones deben implementar medidas administrativas, técnicas y físicas para proteger los datos personales contra daño, pérdida, alteración o acceso no autorizado.
Una API que devuelve datos personales (PII) sin autenticación no cumple con este principio, incluso si el frontend no muestra la información.
Lecciones clave para las organizaciones
- La seguridad no es solo visual: si el navegador recibe datos, el usuario también aunque no sean visibles.
- Las APIs deben devolver solo lo mínimo necesario, siempre.
- DAST y SAST no son opcionales en aplicaciones que procesan datos personales.
- Los flujos de autenticación OTP y registro son objetivos frecuentes y deben probarse con especial cuidado.
- Cumplimiento legal y seguridad técnica van de la mano: una falla técnica puede convertirse en un problema legal.
Este tipo de incidentes no suelen ser producto de mala fe, sino de fallas en los procesos de desarrollo y aseguramiento de la seguridad.
La buena noticia es que también son altamente prevenibles con una estrategia adecuada de pruebas de seguridad y gobierno de datos.
En Cyberseg Solutions ayudamos a las organizaciones a identificar este tipo de riesgos antes de que lleguen a producción, combinando DAST, SAST y análisis de cumplimiento regulatorio para reducir la exposición técnica y legal.
Porque cuando se trata de datos personales, la confianza del usuario y el cumplimiento normativo no admiten errores.
© 2026 Cyberseg Solutions. All rights reserved
