Reports

Vulnerabilidades en APIs: los fallos más comunes y cómo encontrarlos

Guía en castellano sobre seguridad de APIs: exposición excesiva de datos, asignación masiva, versiones olvidadas y falta de límites.

Qué es

Las aplicaciones modernas son, por dentro, un conjunto de APIs: la web y la app móvil son solo clientes que las llaman. Muchos fallos aparecen porque la API confía en que el cliente solo pedirá lo que la interfaz muestra, cuando cualquiera puede llamarla directamente.

Los más frecuentes:

  • Exposición excesiva de datos: la API devuelve el objeto entero (con correo, teléfono o campos internos) y la interfaz solo enseña una parte.
  • Asignación masiva (mass assignment): el servidor copia en la base de datos todos los campos que recibe, incluidos algunos que nunca deberían poder cambiarse, como role o is_admin.
  • Versiones antiguas: /api/v1 sigue activa sin las correcciones que sí tiene /api/v2.
  • Sin límites de uso: endpoints que permiten miles de peticiones por minuto, útiles para fuerza bruta o extracción masiva.
  • Autorización por función rota: endpoints de administración accesibles con un usuario normal.

Dónde mirar

  • Las respuestas JSON completas, no lo que muestra la pantalla.
  • Documentación pública (OpenAPI, Swagger), ficheros JavaScript de la web y aplicaciones móviles, que suelen revelar endpoints no enlazados.
  • APIs GraphQL, donde una sola consulta puede pedir muchos datos y la introspección a veces está activa.

Cómo se busca

  1. Usa la aplicación con un proxy y guarda todas las llamadas a la API.
  2. Lee cada respuesta buscando campos que la interfaz no muestra.
  3. En las peticiones que crean o editan algo, añade campos que aparezcan en las respuestas (role, verified, plan) y comprueba si se guardan.
  4. Cambia la versión de la ruta y repite peticiones protegidas.
  5. Prueba los endpoints de administración con un usuario sin privilegios.

Cómo se evita

  • Definir qué campos devuelve y acepta cada endpoint (esquemas o DTO), en lugar de serializar objetos enteros.
  • Comprobar permisos en cada función y cada objeto, no solo la sesión.
  • Retirar las versiones antiguas o mantenerlas con las mismas correcciones.
  • Límites de uso por usuario y por IP.

Al reportarlo

Explica qué dato concreto se expone o qué campo se puede modificar, y por qué importa. "La API devuelve campos de más" no basta: di cuáles y qué permiten.

Casos reales de APIs

CRÍTICA#3931777

Un autor de WordPress podía borrar cualquier fichero del servidor abusando del endpoint /finalize

Un fallo de path traversal en el endpoint de medios de Gutenberg/WordPress permitía a un usuario con rol Autor borrar archivos arbitrarios del disco, incluido wp-config.php, y quedarse con el control del sitio.

[APIS]wordpress10 visitas
27 sep 2026
6 min
CRÍTICA#4020767

Essity: API sin autenticación de un chatbot interno de Teams permitía leer, escribir y borrar chats de empleados

Las rutas de datos de un chatbot corporativo con Azure OpenAI no pedían credenciales. Con un truco de doble Content-Type para saltar el WAF, se podía además escribir en conversaciones privadas ajenas.

[APIS]essity11 visitas
26 sep 2026
6 min
MEDIA#3617729

Nextcloud Mail: el autocompletado de contactos se salta las restricciones de enumeración de usuarios

El autocompletado de contactos de Nextcloud Mail ignoraba la opción que limita la búsqueda de cuentas al propio grupo, y cualquier usuario autenticado podía listar ID, nombre y email de usuarios de otros grupos.

[APIS]nextcloud
26 sep 2026
2 min
BAJA#3533697

Nextcloud Collectives: un enlace público permitía crear páginas aunque la edición estuviera limitada a administradores

La API de creación de páginas de Nextcloud Collectives no aplicaba la restricción «Allow editing for = Admins only», así que quien entraba por un enlace público de edición podía crear páginas llamando al endpoint directamente.

[APIS]nextcloud11 visitas
24 sep 2026
2 min