MagnoSec
Código de API REST en pantalla representando la guía completa de pentesting de APIs con metodología y herramientas

MagnoSec Blog

Pentesting de APIs REST: Guía Completa de Metodología, Vulnerabilidades y Herramientas

Por Equipo MagnoSec7 min de lectura

Por qué el pentesting de APIs REST es la asignatura pendiente de la seguridad web

Las APIs REST son el sistema nervioso de las aplicaciones modernas. Cada app móvil, cada SPA (Single Page Application), cada integración B2B se comunica con su backend a través de APIs REST. Y sin embargo, las APIs siguen siendo la parte menos auditada de las aplicaciones web. La razón es histórica: los pentesters tradicionalmente se centraban en las aplicaciones web clásicas —formularios, cookies, sesiones—, mientras que las APIs quedaban en segundo plano. Pero el mundo ha cambiado: la mayoría del tráfico malicioso moderno se dirige contra APIs, no contra interfaces web tradicionales. Las APIs manejan los datos más sensibles de las aplicaciones: autenticación, pagos, datos de usuarios, lógica de negocio. Un fallo en una API puede exponer la base de datos completa de una aplicación. Y las herramientas automatizadas de pentesting web clásico no cubren bien las APIs: los escáneres de aplicaciones web están diseñados para páginas HTML, no para endpoints JSON. El pentesting de APIs requiere una metodología específica, herramientas específicas y un entendimiento profundo de los patrones de diseño de APIs. Si tu organización desarrolla o consume APIs REST —y en 2026, todas lo hacen—, el pentesting de APIs no es opcional: es la parte más importante de tu seguridad de aplicaciones.

OWASP API Top 10: las 10 vulnerabilidades más críticas en APIs y cómo detectarlas

El OWASP API Security Top 10 es la referencia para entender las vulnerabilidades más críticas en APIs. 1. BOLA (Broken Object Level Authorization): el atacante manipula identificadores de objetos (IDs) en las peticiones para acceder a recursos de otros usuarios —la vulnerabilidad más común y devastadora en APIs—. 2. BOPLA (Broken Object Property Level Authorization): el atacante envía propiedades no autorizadas en el cuerpo de la petición para modificar campos que no debería (por ejemplo, cambiar su propio rol a 'admin'). 3. Autenticación rota: endpoints que deberían requerir autenticación no la requieren, o la implementan mal. 4. Autorización a nivel de función rota: usuarios normales pueden acceder a funciones administrativas cambiando el método HTTP o el endpoint. 5. Exposición excesiva de datos: las APIs devuelven más datos de los necesarios, confiando en que el cliente filtrará los campos sensibles. 6. Asignación masiva: el atacante envía campos adicionales en la petición que la API asigna automáticamente al modelo de datos. 7. Inyección: SQL, NoSQL y command injection en parámetros de la API. 8. Mala gestión de recursos: sin rate limiting, un atacante puede hacer fuerza bruta o DoS. 9. Configuración incorrecta: cabeceras de seguridad ausentes, errores detallados, CORS mal configurado. 10. Logging y monitorización insuficientes: sin registros, los ataques pasan desapercibidos. Estas diez categorías cubren la mayoría de las vulnerabilidades que encontramos en auditorías reales de APIs. Y BOLA y BOPLA —los dos primeros— son los más frecuentes y los más peligrosos.

Metodología de pentesting de APIs: del descubrimiento de endpoints a la explotación

La metodología de pentesting de APIs sigue un proceso estructurado. Fase 1 —descubrimiento—: identificar todos los endpoints de la API. Esto incluye leer la documentación (Swagger/OpenAPI si está disponible), analizar el tráfico de la aplicación cliente (la app móvil o SPA revela todos los endpoints que consume), y realizar fuzzing de rutas para encontrar endpoints no documentados. Muchas APIs tienen endpoints internos o legacy que no aparecen en la documentación y que suelen ser los menos protegidos. Fase 2 —mapeo de funcionalidad—: para cada endpoint, documentar el método HTTP, los parámetros requeridos y opcionales, los roles que pueden acceder, y la respuesta esperada. Fase 3 —pruebas de autenticación—: verificar que todos los endpoints que requieren autenticación la implementan correctamente, probar bypasses (cambiar el método HTTP, manipular tokens, probar endpoints sin token), y evaluar la gestión de sesiones. Fase 4 —pruebas de autorización—: la parte más importante del pentesting de APIs. Probar BOLA (acceder a objetos de otros usuarios cambiando IDs), BOPLA (enviar propiedades no autorizadas), y autorización a nivel de función (acceder a funciones admin con credenciales de usuario normal). Fase 5 —pruebas de validación de entradas—: inyecciones SQL/NoSQL/command, XXE, deserialización insegura, y manipulación de tipos de datos. Fase 6 —pruebas de configuración—: cabeceras de seguridad, CORS, rate limiting, manejo de errores. Fase 7 —documentación—: cada hallazgo con evidencia, impacto y recomendación de remediación. La clave del pentesting de APIs es la fase 4: la mayoría de las APIs fallan en autorización, no en autenticación. La autenticación te dice quién eres. La autorización decide qué puedes hacer. Y es la autorización la que los desarrolladores implementan mal con más frecuencia.

Herramientas profesionales para auditar APIs REST: Postman, Burp, fuzzing y más

Las herramientas del pentesting de APIs se dividen en cuatro categorías. Interceptación y manipulación: Burp Suite sigue siendo el estándar para interceptar y modificar peticiones HTTP —configurado para manejar JSON, con extensiones específicas para APIs—. Postman permite construir colecciones de peticiones, organizar endpoints por funcionalidad y automatizar pruebas. Mitmproxy es una alternativa open-source. Descubrimiento: para APIs sin documentación, herramientas de fuzzing de rutas como ffuf, gobuster y kiterunner (específica para APIs, usa wordlists basadas en OpenAPI specs) descubren endpoints ocultos. La documentación Swagger/OpenAPI, si está expuesta, es una mina de oro —muchas organizaciones exponen su spec completa sin darse cuenta—. Fuzzing: herramientas como Arjun (descubrimiento de parámetros), Param Miner (extensión de Burp para descubrir parámetros ocultos), y JQ para procesar respuestas JSON en scripts de prueba. Automatización: Postman con scripts de test, Insomnia, y frameworks de testing de APIs como RestAssured o Karate permiten automatizar suites de pruebas completas. Una combinación típica de pentester profesional: Burp Suite para interceptación manual, kiterunner para descubrimiento de endpoints, Arjun para parámetros ocultos, y scripts personalizados en Python para pruebas automatizadas de BOLA (iterando sobre IDs de objetos). La automatización de las pruebas de BOLA es esencial: probar manualmente 10.000 combinaciones de IDs es inviable; un script lo hace en minutos.

BOLA, BOPLA y autorización rota: las vulnerabilidades que rompen la seguridad de las APIs

BOLA y BOPLA merecen una explicación detallada porque son las vulnerabilidades que encontramos con más frecuencia en auditorías de APIs y las que tienen el impacto más directo. BOLA (Broken Object Level Authorization): imagina una API bancaria donde el endpoint GET /api/v1/cuentas/{id} devuelve los datos de la cuenta especificada. El desarrollador ha implementado la autenticación correctamente —solo usuarios logueados pueden llamar al endpoint—, pero ha olvidado verificar que el usuario logueado es el propietario de la cuenta. El atacante, autenticado con su propia cuenta, simplemente cambia el ID en la URL: GET /api/v1/cuentas/12345 en lugar de /api/v1/cuentas/67890. Si la API devuelve los datos de la cuenta 12345 —que pertenece a otro cliente—, el atacante acaba de robar los datos de otro usuario. Y puede iterar: 12346, 12347, 12348... hasta extraer la base de datos completa de cuentas. BOPLA (Broken Object Property Level Authorization): imagina una API donde el endpoint PATCH /api/v1/usuarios/{id} permite a los usuarios actualizar su perfil. El desarrollador ha verificado que el usuario solo puede modificar su propio perfil, pero no ha restringido qué campos pueden modificarse. El atacante envía PATCH /api/v1/usuarios/67890 con el cuerpo {'rol': 'admin'}. La API asigna automáticamente el campo 'rol' al modelo de usuario. El atacante acaba de convertirse en administrador. Ambas vulnerabilidades comparten la misma causa raíz: la autorización se implementa a nivel de autenticación (¿estás logueado?) pero no a nivel de objeto (¿puedes acceder a ESTE objeto?) ni a nivel de propiedad (¿puedes modificar ESTA propiedad?). La corrección requiere verificación de autorización en cada endpoint, para cada objeto, para cada campo. Es tedioso pero esencial. Y es exactamente lo que comprobamos en nuestras auditorías de APIs.

Cómo MagnoSec realiza pentesting de APIs REST en sus auditorías web

En MagnoSec, el pentesting de APIs REST es una parte integral de nuestras auditorías web. Comenzamos con un mapeo completo de la superficie de API: documentación, tráfico de la aplicación cliente, y descubrimiento activo de endpoints. Aplicamos la metodología OWASP API Top 10 de forma sistemática, con énfasis especial en BOLA y BOPLA —las vulnerabilidades que más impacto tienen y que las herramientas automáticas detectan peor—. Utilizamos Burp Suite para el análisis manual, herramientas de fuzzing para el descubrimiento de endpoints y parámetros, y scripts personalizados para las pruebas automatizadas de autorización. Cada vulnerabilidad encontrada se explota de forma controlada para demostrar su impacto real, se documenta con evidencia técnica y se clasifica según CVSS. El informe incluye recomendaciones específicas para tu stack tecnológico y tu modelo de datos. Y ofrecemos re-test post-remediación para verificar que las correcciones son efectivas. Si tu organización expone APIs REST —internas o externas—, una auditoría de API es la inversión de seguridad más rentable que puedes hacer. Las APIs son el acceso directo a tus datos. Asegúrate de que solo las personas adecuadas pueden acceder a ellos.

Temas tratados

pentesting APIs REST · API security · OWASP API Top 10 · BOLA · auditoría API · pentesting api · API pentest

Preguntas frecuentes

¿Qué es un pentesting de APIs REST?

Es una auditoría de seguridad específica para APIs REST: se prueban los endpoints buscando fallos de autorización a nivel de objeto (BOLA), asignación masiva de parámetros, autenticación rota, exposición excesiva de datos y ausencia de limitación de peticiones. OWASP publica un Top 10 específico de riesgos de API que sirve como marco de referencia.

¿Qué es BOLA y por qué es la vulnerabilidad más común en APIs?

BOLA (Broken Object Level Authorization) ocurre cuando un endpoint acepta un identificador de objeto y no comprueba si el usuario que lo pide tiene permiso sobre ese objeto. Es la vulnerabilidad número uno del OWASP API Top 10 porque es fácil de introducir, frecuente en el código real y permite acceder a datos de otros usuarios cambiando un número en la petición.

¿Cuánto cuesta un pentesting de API?

Entre 1.200€ y 4.500€ para la mayoría de APIs, en función del número de endpoints, de los roles de usuario y de si hay integraciones con terceros. Una API con 20 endpoints y dos roles se audita desde 1.200€; una API pública con cientos de endpoints y varios niveles de permisos se acerca a 4.500€.

¿Cuánto dura un pentesting de API?

Entre una y tres semanas. Una API sencilla con pocos endpoints se cubre en una semana; una API compleja con varios roles, integraciones y lógica de negocio propia requiere dos o tres semanas, porque hay que entender el modelo de permisos antes de poder probar los fallos de autorización.

¿Quieres saber si tu empresa tiene estas vulnerabilidades?

Auditamos la seguridad de empresas de toda España con alcance cerrado por escrito, informe técnico y ejecutivo, y retest de las correcciones. Presupuesto en 24 horas y primera consultoría sin coste. Si no sabes por dónde empezar, haz el test de seguridad de 15 preguntas.

¿Quieres más información?