Reports
BAJA[EXPOSICIÓN DE DATOS]#3027405

Departamento de Defensa de EE. UU.: el endpoint /users devolvía datos personales y auth_data sin autenticación

Un endpoint de la API de un sitio del Departamento de Defensa de EE. UU. devolvía a cualquier visitante, sin iniciar sesión, el nombre, email, rol y datos de autenticación de los usuarios.

Resumen
Resumen en castellano de un reporte público, no una traducción literal. El código y los comandos se mantienen como en el original.

Resumen

En uno de los sistemas incluidos en el programa de divulgación del Departamento de Defensa de EE. UU. (el host aparece censurado en el reporte), el endpoint de usuarios de la API respondía sin pedir ningún tipo de autenticación. Su respuesta incluía, por cada usuario, estos campos:

  • id
  • nombre y apellidos
  • email
  • rol (role)
  • auth_data, datos relacionados con la autenticación

Bastaba con pedir la ruta desde un navegador sin sesión para obtener la lista. El reporte está clasificado como divulgación de información (Information Disclosure) con severidad baja. Se envió el 9 de marzo de 2025, se marcó como resuelto y se hizo público el 12 de enero de 2026.

Pasos de reproducción

  1. Sin haber iniciado sesión, abre el sitio afectado (su dirección está censurada en el reporte).
  2. Pide la ruta del endpoint de usuarios. En el texto se nombra como /user, pero la petición de ejemplo usa /users:
GET /users HTTP/2
Host: ██████████
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.6613.127 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Priority: u=0, i
Te: trailers
  1. Revisa la respuesta: contiene los datos de los usuarios descritos arriba, aunque la petición no lleva cookies ni cabecera Authorization.

Impacto

Según el investigador, cualquiera podía:

  • Recopilar información personal identificable (nombres y correos) de los usuarios del sistema.
  • Saber qué rol tiene cada cuenta y dirigir campañas de phishing o ingeniería social contra ellas.
  • Leer el campo auth_data, que podría servir de apoyo para otros ataques o para un acceso no autorizado. El reporte no detalla qué contenía exactamente ese campo.

Qué aprender de este caso

  • Prueba los endpoints de colección (/users, /user, /api/users) sin cookies ni token: es habitual que el control de acceso esté solo en la interfaz de la aplicación y no en la propia API.
  • Prueba las variantes en singular y plural de la misma ruta; aquí el propio reporte alterna /user y /users, y a veces solo una de ellas está protegida.
  • Al programar, define qué campos salen en cada respuesta (una lista blanca) en lugar de serializar el objeto de usuario entero: un campo como auth_data nunca debería llegar al cliente, ni siquiera a uno autenticado.
  • Exige autenticación por defecto en todo el enrutado de la API y abre explícitamente solo las rutas públicas, en vez de proteger las rutas una a una.