Casi todo el mundo ve el informe antes que el método. Esto es el método: siete fases, qué tiene que estar listo antes de que se envíe la primera petición, cuánto dura, qué recibes y qué cosas deja fuera un test de aplicación web a propósito.
Un pentest de aplicación web es trabajo autorizado, acotado en el tiempo y en su mayor parte manual contra una aplicación en funcionamiento, hecho por gente que intenta usarla de maneras para las que no se diseñó. La herramienta automática aparece en una sola fase, para dar cobertura; no es de donde salen los hallazgos que cambian una hoja de ruta.
El Data Breach Investigations Report 2026 de Verizon, construido sobre más de 22.000 brechas confirmadas en 145 países, sitúa la explotación de vulnerabilidades como el vector de acceso inicial más frecuente, con un 31%, y baja el abuso de credenciales al 13%. La clase de fallo web dominante no se ha movido: en el OWASP Top 10:2025 el control de acceso roto ocupa el primer puesto, y el propio proyecto declara que el 100% de las aplicaciones de su conjunto de datos tenía alguna forma de control de acceso roto.
No se toca nada hasta que la frontera está escrita. El alcance nombra los dominios y los equipos que entran, el entorno, los roles que se van a probar y, con la misma importancia, lo que queda fuera: el SaaS compartido que no es tuyo, las pasarelas de pago y cualquier cosa cuyo proveedor no haya autorizado que se pruebe.
Esa frontera vive en las rules of engagement. NIST SP 800-115 publica una plantilla en su anexo B: propósito, alcance, supuestos y limitaciones, riesgos y personas de contacto con nombre por cada parte. Fija también la ventana de pruebas, cualquier exclusión de denegación de servicio y cómo se marca el tráfico de prueba, para que un incidente de verdad no se confunda nunca con él.
La guía de pruebas de OWASP recomienda que el cliente enseñe la aplicación a quien va a probarla antes de que empiecen las pruebas de verdad.
NIST SP 800-115 llama a esto la fase de descubrimiento y la parte en dos: recogida de información y escaneo, y después análisis de vulnerabilidades. En una aplicación web eso significa inventariar lo que está expuesto antes de elegir qué atacar. Enumerar equipos y subdominios, identificar servidor y framework, leer los metaficheros y los ficheros viejos que nadie retiró, y recorrer los caminos de ejecución como cada uno de los roles por turno.
El escaneo automático pertenece a esta fase y a ninguna otra. Es bueno en anchura: versiones conocidas de componentes, cabeceras que faltan, rutas por defecto, CVE públicos en código de terceros. Es inútil para todo lo del apartado siguiente. Lo que sale es un inventario de endpoints, parámetros, roles y transiciones de estado. No es un entregable.
Aquí es donde un test de web deja de parecerse a cualquier otro proyecto. El modelado de amenazas ordena los escenarios de ataque por probabilidad y por impacto en el negocio; el análisis de vulnerabilidades los recorre contra las doce categorías de la OWASP Web Security Testing Guide, versión estable 4.2.
Registro, inicio de sesión, restablecimiento de contraseña, bloqueo de cuenta, alta y recuperación del segundo factor, emisión y caducidad de la sesión, y los canales que se saltan todo eso en silencio. Los flujos de restablecimiento llevan dentro más lógica que el propio inicio de sesión y reciben menos escrutinio. El tiempo también cuenta: hay condiciones de carrera en el descubrimiento de proveedores de identidad que solo aparecen cuando las peticiones se lanzan a la vez, y que ninguna pasada secuencial encuentra.
Donde está la mayor parte del valor. Cada identificador de objeto se manipula desde una sesión con menos privilegios, para ver si el servidor comprueba la propiedad o si lo único que pasaba es que la interfaz escondía el enlace, que es exactamente lo que es una referencia directa insegura a objetos. Cada función privilegiada se invoca de forma directa. En una aplicación multiinquilino la matriz se repite además entre inquilinos.
Cada parámetro que llega a un analizador, a una consulta, a una plantilla, a una ruta o a una petición saliente: inyección SQL, cross-site scripting, inyección de plantillas, deserialización, salto de directorio. OWASP señala que la inyección acumula el mayor número de CVE de los 38 tipos de fallo que agrupa.
Pasos que se saltan, precios que cambian después de la pantalla de resumen, cantidades en negativo, flujos que se repiten. Un fallo de lógica de negocio, según la propia OWASP, no lo detecta ningún escáner de vulnerabilidades y depende de la pericia y de la imaginación de quien prueba.
Un candidato no es un hallazgo hasta que se ha demostrado. NIST lo dice sin rodeos: mientras un escáner de vulnerabilidades solo comprueba la posible existencia de una vulnerabilidad, la fase de ataque de un pentest la explota para confirmar que existe.
Aquí pasan dos cosas que ningún escaneo puede hacer. La primera es el encadenado: NIST observa que la mayoría de los tests buscan combinaciones de vulnerabilidades que permitan obtener más acceso del que daría una sola, y así es como una fuga de severidad baja más un endpoint olvidado acaban siendo un compromiso. La segunda es el bucle de vuelta al descubrimiento. Una falsificación de peticiones del lado del servidor deja de ser un hallazgo web en el momento en que alcanza los metadatos del proveedor cloud, y a partir de ahí el problema es de la cuenta, no de la aplicación.
La postexplotación mide el impacto en vez de afirmarlo: qué datos se podrían leer, cambiar o borrar, y de quién. Cada hallazgo demostrado deja una prueba de concepto que tus desarrolladores pueden repetir. La contención forma parte del método: NIST señala que un test se puede diseñar para detenerse cuando la siguiente acción causaría daño, así que la prueba se para en el último paso seguro.
El informe no es la última semana del proyecto. NIST lo describe corriendo en paralelo a las demás fases, con registros que se guardan de principio a fin e informes periódicos a la dirección. Cualquier cosa crítica se comunica el día en que se confirma, no se guarda para el documento.
Cuando las correcciones están desplegadas, un retest vuelve a ejecutar las pruebas originales contra los hallazgos originales y registra cada uno como cerrado, corregido a medias o todavía abierto. Corregido a medias sale más veces de lo que nadie espera: el payload del informe deja de funcionar y una variante suya no. El informe y la atestación se reemiten contra el estado ya comprobado.
Los datos del sector enseñan lo que cuesta saltarse esto. 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% del año anterior, mientras la mediana de tiempo hasta la resolución completa subió de 32 a 43 días.
Para una sola aplicación web, cuenta con una o dos semanas de pruebas activas, precedidas de aproximadamente una semana de alcance, papeleo y accesos, y seguidas del informe. El retest es más corto y llega semanas después. Son rangos de planificación: la primera reunión los convierte en fechas.
Lo que mueve el número no es el número de pantallas. Es esto:
Si un auditor pregunta qué metodología siguió tu test, la respuesta debería ser un documento que pueda abrir. La página del servicio de pentesting de aplicación web detalla qué probamos y qué necesitamos de ti.
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.
Un relato claro de un pentest de API, de las rules of engagement al retest: qué pasa en cada fase, qué recibes al final y hasta dónde llega lo que este test te puede decir.
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.
