Un pentest de API es el navegador quitado de la ecuación. Esta es la secuencia que sigue un proyecto real, qué tiene que estar listo antes de la primera petición, cuánto suele tardar cada forma de API y qué preguntas no responde este test.
Un pentest de API es un ataque autorizado, y en su mayor parte manual, contra las interfaces que tus sistemas exponen a otros sistemas: endpoints REST, esquemas de GraphQL, servicios gRPC, webhooks y los servidores que hay detrás de tus aplicaciones móviles. La NIST SP 800-115 describe el pentest como una prueba de seguridad en la que quien evalúa imita ataques reales para encontrar formas de rodear las funciones de seguridad de una aplicación, un sistema o una red.
Un pentest de API es eso mismo con el navegador quitado de la ecuación, y quitarlo es justamente el punto. Quien llama a una API envía lo que quiere, en el orden que quiere, con el token que tenga, así que cada supuesto que tu front imponía en silencio hay que imponerlo otra vez en el servidor.
El Data Breach Investigations Report 2026 de Verizon pone la explotación de vulnerabilidades en el 31% de las brechas con vector de acceso inicial conocido, frente al 20% anterior, lo que la convierte en la vía de entrada más frecuente, por delante del abuso de credenciales con un 13%.
NIST es explícito en que en la fase de planificación no se prueba nada: su trabajo es identificar las reglas, cerrar la aprobación de la dirección y fijar los objetivos de las pruebas. Las rules of engagement duran más que el test, y en una API responden a bastante más que a qué equipos entran.
/v1 responde igual que /v3, las dos entran en el alcance.El OWASP API Security Top 10 recoge la gestión inadecuada del inventario como API9:2023 y describe la amenaza como atacantes que consiguen acceso no autorizado a través de versiones o endpoints de API antiguos que se quedaron funcionando sin parchear y con requisitos de seguridad más flojos. Sus preguntas merecen respuesta, contrates o no a nadie: en qué entorno está este equipo, quién debería alcanzarlo y qué versión sirve.
NIST parte el descubrimiento en dos: recogida de información y escaneo, y después análisis de vulnerabilidades. En una API la primera mitad es trabajo de inventario, y tu especificación es un punto de partida, no la respuesta.
La lista de endpoints se construye desde varias direcciones a la vez: la especificación, el tráfico que produce un cliente real cuando se recorren sus flujos de punta a punta, los paquetes de JavaScript y los binarios móviles que llaman a la API, y los patrones de ruta extrapolados de lo que ya se conoce. Los endpoints que responden y no aparecen en ninguna especificación son API en la sombra, y son de lo que habla API9:2023: rutas olvidadas corriendo sin parchear y con requisitos de seguridad más flojos, porque nada de lo que revisa la superficie documentada las miró nunca.
En paralelo dibujamos el modelo de identidad: cómo se emite un token, qué lleva dentro y si los ámbitos de OAuth 2.0 y las declaraciones del JWT se comprueban en el servidor de recursos o solo en el borde. API2:2023 enumera las formas en que eso sale mal, incluidas las API que aceptan tokens sin firmar y las que no validan nunca la fecha de caducidad.
Cada tipo de pentest tiene una fase que le pertenece solo a él. En las API es la autorización: el OWASP API Security Top 10 le dedica tres de sus diez entradas, a la autorización rota a nivel de objeto (API1:2023), a nivel de propiedad de objeto (API3:2023) y a nivel de función (API5:2023).
La regla de OWASP cabe en una frase: cada endpoint que recibe el identificador de un objeto y hace cualquier cosa con ese objeto debería aplicar comprobaciones de autorización a nivel de objeto. La autorización rota a nivel de objeto es lo que queda cuando no lo hace, y OWASP la califica de fácil de explotar, extendida y fácil de detectar. Se prueba en cada parámetro que nombre un objeto, no en una muestra.
GET /v2/invoices/8842
Authorization: Bearer <usuario A, dueño de 8842>
200 OK
GET /v2/invoices/8842
Authorization: Bearer <usuario B, de otro inquilino>
200 OK <- el hallazgo
API3:2023 juntó dos entradas de la edición de 2019, la exposición excesiva de datos y la asignación masiva, en una sola idea: el objeto es tuyo, pero no todas sus propiedades lo son. Una respuesta devuelve campos que quien llama no debería ver nunca, o la asignación masiva añade "role": "admin" a un cuerpo que el servidor enlaza directamente contra su modelo.
La autorización rota a nivel de función aplica el mismo fallo a las operaciones: un endpoint que un usuario normal no debería invocar nunca, alcanzado cambiando el verbo, adivinando la ruta administrativa o repitiendo una petición de una sesión con privilegios. Las pruebas que salen bien son aburridas: cambiar GET por PUT y por DELETE, y llamar con un token de pocos privilegios a cada ruta administrativa que apareciera en el reconocimiento.
Inyección a través de parámetros que no pasan por ningún formulario, falsificación de peticiones del lado del servidor a través de campos de URL que el servidor descarga por ti, y consumo de recursos. API4:2023 enumera los límites que deberían existir y que casi nunca están todos: tiempos máximos de ejecución, tamaño de subida, registros por página, límites de gasto con terceros y operaciones por petición, que en GraphQL significa agrupación y profundidad de consulta. La OWASP Web Security Testing Guide cubre GraphQL como la prueba WSTG-APIT-01.
Por último llega lo único que ningún escáner encuentra: API6:2023, acceso sin restricciones a flujos de negocio sensibles. El ejemplo que pone OWASP es comprar todo el stock de un artículo muy demandado para revenderlo. Nada de esa petición está mal formado; el fallo es que el flujo se dejó automatizar.
NIST traza la raya con precisión: mientras los escáneres de vulnerabilidades solo comprueban la posible existencia de una vulnerabilidad, la fase de ataque de un pentest la explota para confirmar que existe. Nada llega al informe como confirmado hasta que se ha reproducido.
La fase hace bucle. El diagrama de cuatro etapas de NIST dibuja un camino de realimentación que vuelve del ataque al descubrimiento, y su texto señala que la mayoría de los pentests buscan combinaciones de vulnerabilidades que dan más acceso del que daría cualquiera de ellas por separado. Cada exploit que funciona devuelve material nuevo al reconocimiento, y por eso un test de API produce cadenas en vez de una lista plana.
La verificación se queda del lado conservador. Leer un registro que pertenece a otro inquilino demuestra el fallo de aislamiento; enumerar el inquilino convierte un test en un incidente. NIST reconoce con franqueza que los sistemas se pueden dañar durante un pentest y que la experiencia de quien prueba reduce ese riesgo sin eliminarlo del todo. Por eso la regla de parada se acuerda en la fase uno.
NIST señala que la fase de informe ocurre a la vez que las otras tres, y así es como debería notarse: un hallazgo crítico se comunica el día en que se confirma, no en un PDF tres semanas después. El Penetration Testing Execution Standard organiza el mismo trabajo en siete apartados, de las interacciones previas al encargo y la recogida de inteligencia al informe, pasando por modelado de amenazas, análisis de vulnerabilidades, explotación y postexplotación.
Un hallazgo está cerrado cuando se ha demostrado que está cerrado. Un retest vuelve a ejecutar los pasos de reproducción de cada problema que corregiste y, cuando la corrección toca código compartido, comprueba los endpoints vecinos que seguían el mismo patrón. Un cambio aplicado a un controlador mientras otros once conservan la forma antigua sigue leyéndose como corregido, si el único endpoint del retest es el que nombraba el informe.
El DBIR 2026 encontró que las organizaciones solo remediaron por completo el 26% de las vulnerabilidades críticas durante 2025, entendiendo por críticas las del catálogo de vulnerabilidades explotadas conocidas de CISA, frente al 38% anterior, y que la mediana de tiempo hasta la resolución completa subió de 32 a 43 días. Ese catálogo tenía 1.655 entradas en la versión publicada el 27 de julio de 2026.
Formas, no promesas. Lo útil de saber antes de preguntar es que lo que manda no es el número de endpoints.
Lo que mueve el número son los roles multiplicados por los tipos de objeto, y no el número de endpoints, así que dos inquilinos de más añaden más trabajo que veinte endpoints de más; que exista una especificación usable, porque reconstruir una a mano puede comerse buena parte del proyecto; y la calidad del entorno, porque una preproducción con las tablas vacías esconde justo los hallazgos para los que existe el test.
Los días de trabajo se ponen por escrito una vez hemos visto la superficie. Cualquier número que se dé antes de eso es una suposición con una coma decimal.
Nuestro servicio de pentesting de API sigue esta secuencia. El mismo recorrido existe para cómo funciona un pentest web y para cómo funciona un pentest de aplicación móvil, y la forma que comparten todos está en nuestra metodología de pentesting.
Todas las cifras y todas las referencias a marcos de este artículo salen de estos documentos.
La secuencia real de un pentest de red externa: alcance y rules of engagement, reconocimiento, análisis del perímetro, explotación, informe y retest, además de lo que el test no va a cubrir.
La secuencia de un pentest de red interna real: el punto de partida que acordamos, en qué se convierte una cuenta de dominio, qué recibes al final, cuánto dura y qué cosas no cubre el ejercicio a propósito.
Las siete fases de un pentest de aplicación web, qué tiene que estar listo antes del primer día, cuánto dura, qué recibes al final y qué cosas deja fuera a propósito.
Si algo de aquí se parece a un problema que llevas encima, media hora de llamada para acotarlo con un pentester senior vale más que leer otro artículo.
Hablar con un pentester seniorElige la hora que mejor te venga. Nos cuentas qué necesitas y en qué punto estás, y te explicamos cómo trabajamos y de qué forma podemos ayudarte.
