¿Cómo estructuras una prueba de aplicación web usando la OWASP WSTG?
Respuesta breve
La WSTG es una metodología respaldada por una lista de verificación que recorre una aplicación a través de categorías de prueba: recopilación de información, configuración y despliegue, identidad y autenticación, autorización, gestión de sesiones, validación de entradas (inyección/XSS), gestión de errores, criptografía, lógica de negocio y lado cliente. Ofrece cobertura sistemática con identificadores de prueba estables, de modo que los hallazgos son reproducibles y no se omite nada obvio.
La OWASP Web Security Testing Guide (WSTG) convierte «prueba la aplicación web» en un proceso sistemático y repetible. Los entrevistadores recurren a ella porque un tester experimentado no hurga en URLs al azar — recorre un conjunto estructurado de categorías para que la cobertura sea demostrable y los hallazgos lleven identificadores estables que otros puedan reproducir.
Las categorías de prueba
La WSTG organiza las pruebas en una progresión lógica:
- Recopilación de información. Identificar el servidor, los frameworks, los puntos de entrada y mapear la superficie de ataque de la aplicación.
- Gestión de configuración y despliegue. TLS, cabeceras HTTP, ficheros por defecto, interfaces de administración, malas configuraciones de nube e infraestructura.
- Identidad y autenticación. Enumeración de cuentas, políticas de credenciales débiles, evasión de MFA, fallos de recuperación de contraseña.
- Autorización. Escalada de privilegios, referencias directas inseguras a objetos (IDOR), traversal de rutas — ¿la aplicación impone quién puede hacer qué?
- Gestión de sesiones. Robustez de tokens, fijación, cierre de sesión, atributos de cookies.
- Validación de entradas. La familia clásica de inyecciones — SQLi, XSS, SSRF, inyección de comandos.
- Gestión de errores y criptografía. Fuga de información, cifrados débiles, manejo inadecuado de claves.
- Lógica de negocio. Abuso de funciones legítimas — los fallos que los escáneres no pueden encontrar.
- Lado cliente. DOM XSS, CORS, postMessage y problemas de JavaScript que viven en el navegador.
Por qué importa la estructura
Las categorías imponen cobertura: un escáner encuentra un XSS reflejado pero nunca entiende que «saltarse el paso de pago y aun así obtener la mercancía» es el verdadero fallo. Los identificadores de prueba estables (p. ej. WSTG-ATHZ) te permiten mapear hallazgos, seguir el progreso y entregar a un equipo de remediación algo reproducible.
Qué buscan los entrevistadores
Quieren verte combinar automatización con profundidad manual — usar DAST para cubrir la amplitud, y luego dedicar tiempo humano a la autorización y la lógica de negocio, las categorías que realmente requieren un atacante que piensa.
Posibles preguntas de seguimiento
- ¿Cómo pruebas los fallos de lógica de negocio que los escáneres no pueden encontrar?
- ¿Cuál es la diferencia entre las pruebas de autenticación y de autorización en la WSTG?
- ¿Cómo combinarías la WSTG con DAST automatizado sin ahogarte en falsos positivos?