Information disclosure in REST APIs

Una aplicación web suele proteger sus vistas (login, autorización por rol), pero su API REST a menudo no aplica el mismo control. Endpoints como /api/user/, /api/users, /api/v1/accounts pueden devolver objetos internos completos, incluyendo campos sensibles que el frontend nunca muestra: contraseñas en claro, hashes, tokens, correos, roles.

Descubrir la API

El patrón es localizar la raíz de la API y recorrer los recursos que ofrece. La documentación autogenerada suele ser la mina más rápida:

feroxbuster -u http://<ip>:<port>/ -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt
curl -s http://<ip>:<port>/api/ | jq                     # indice de la API
curl -s http://<ip>:<port>/swagger.json                  # o /openapi.json, /api-docs, /swagger-ui/
curl -s http://<ip>:<port>/api/v1/users | jq

Un swagger.json/openapi.json lista todos los endpoints, sus parámetros y sus esquemas: es el mapa completo de la superficie de ataque. Para parámetros ocultos, arjun los descubre por fuerza bruta.

GraphQL

Si la API es GraphQL (/graphql, /graphql-api), la introspección revela el esquema entero (tipos, campos, mutaciones), incluidos los que la interfaz nunca usa:

curl -s http://<ip>/graphql -H 'Content-Type: application/json' \
  -d '{"query":"{__schema{types{name fields{name}}}}"}' | jq

Cuando el endpoint responde con la tabla de usuarios y sus contraseñas en texto plano, el salto a acceso es inmediato: esas credenciales suelen valer en otros servicios (SSH, panel, VPN) por reutilización de credenciales.

Requisitos

Alcance a la API y que esta exponga datos sin la autorización adecuada. No toda API sin auth es una fuga: hay endpoints públicos por diseño. Lo grave es exponer campos que deberían filtrarse (contraseñas, PII) o que requieren autorización por rol.

Es una variante de Broken Access Control / Excessive Data Exposure del OWASP API Security Top 10: el fallo no es solo que falte autenticación, sino que el serializador devuelve más campos de los que el cliente debería ver. Distinto del IDOR (acceso a recursos de otros manipulando un identificador), aquí el problema es exponer datos sensibles de forma masiva.

Cómo detectarlo. Del lado del servidor, la firma es de enumeración: un mismo origen recorriendo muchos endpoints (feroxbuster/dirsearch genera cientos de peticiones con User-Agent de herramienta y ráfagas de 404/403), una consulta de introspección GraphQL (que ninguna app cliente lanza en producción), o accesos a swagger.json/openapi.json desde una IP externa. Respuestas 200 grandes en /api/users hacia un cliente no autenticado, o la descarga completa de una colección, son la señal de la exfiltración.

Defensa. Aplicar el mismo control de acceso que el frontend, devolver solo los campos necesarios (DTOs/serializadores explícitos, nunca el modelo entero), nunca almacenar ni devolver contraseñas en claro, desactivar la introspección de GraphQL en producción y autenticar/autorizar cada endpoint. Relacionado con las credenciales en el código y el control de acceso roto.