OWASP WSTG

Objetivos: qué te aporta un test conducido según la WSTG

Elegir una metodología pública no es un adorno del presupuesto. Cambia lo que recibes al final y lo que puedes hacer con ello. Según el contexto, un proyecto montado sobre esta guía persigue uno o varios de estos objetivos.

• Una cobertura demostrable. La lista de casos de prueba ejecutados y, sobre todo, la de los descartados con su motivo. Es la única forma de responder con honestidad a la pregunta «¿qué mirasteis?» seis meses después.
• Salir del terreno de las herramientas. El control de acceso, la lógica de negocio y el encadenamiento de pasos de un proceso no se detectan solos. Son también las categorías de las que salen nuestros hallazgos más graves.
• Priorizar la corrección por el riesgo real en tu contexto: la puntuación CVSS, sí, pero también qué dato se alcanza, a cuántas cuentas afecta y cuánto esfuerzo cuesta explotarlo.
• Poder comparar campañas. De un test al siguiente, los mismos identificadores permiten medir una evolución en lugar de empezar de cero cada vez.
• Documentar un proceso de pruebas regular en el sentido del art. 32.1.d) del RGPD, y alimentar con evidencia técnica un expediente de ISO 27001 o una auditoría del ENS.
• Darle a tu equipo de desarrollo con qué corregir: una petición que se puede repetir, una captura, una corrección propuesta y el caso de prueba que hay que volver a pasar.

La WSTG es una trama aplicativa. Vale para el pentesting de aplicaciones web y para las APIs; para una infraestructura interna, un entorno cloud o una operación ofensiva completa la trama es otra, y la encontrarás en nuestros tests de intrusión.

Qué obliga realmente en España

Buena parte del mercado lleva dos años vendiendo pentesting con el argumento de NIS2. Conviene decirlo sin rodeos: NIS2 no está transpuesta en España. El Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad solo ha pasado una primera lectura en Consejo de Ministros, el 14 de enero de 2025, y nunca ha llegado a las Cortes. El 9 de julio de 2026 la Comisión Europea llevó a España ante el Tribunal de Justicia de la Unión Europea por esa falta de transposición, en el procedimiento INFR(2024)0270. Lo contamos con detalle en NIS2 en España: qué obliga hoy y qué no.

Lo que sí está en vigor —y lo que convierte «tener una metodología escrita» en algo más que una buena costumbre— es esto:

• Reglamento de Ejecución (UE) 2024/2690. De aplicación directa, sin necesidad de transposición. Su Anexo, en el punto 6.5 «Pruebas de seguridad», exige una política de pruebas documentada, un alcance y una periodicidad determinados por el riesgo, una metodología y unos resultados documentados, y la corrección de los hallazgos críticos. «Metodología documentada» es literalmente lo que aporta la WSTG: categorías, casos de prueba identificados y una cobertura que se puede enseñar. Es la obligación de pruebas más concreta que hay hoy sobre la mesa, y casi nadie la cita.
• RDL 12/2018 y RD 43/2021. Trasponen la directiva NIS original y siguen siendo el marco vigente para operadores de servicios esenciales y proveedores de servicios digitales, con sus obligaciones de auditoría y de análisis de riesgos periódicos.
• ENS, RD 311/2022. El art. 31 impone una auditoría regular ordinaria al menos cada dos años, y el art. 38 separa la autoevaluación de la categoría BÁSICA de la certificación exigida en MEDIA y ALTA. En el Anexo II, el refuerzo [op.mon.3] R6 incluye el subrequisito [op.mon.3.r6.3], titulado literalmente «Pruebas de penetración», exigible en categoría ALTA. Y ya desde BÁSICA, op.nub.1.2 a) pide la «Auditoría de pruebas de penetración (pentesting)» de los servicios cloud de terceros que no sean conformes con el ENS. Ahí el informe estructurado por WSTG entra como evidencia técnica; quién firma la auditoría es otra cuestión, y la tratamos en quién puede auditar el ENS.
• RGPD, art. 32.1.d). Exige «un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas para garantizar la seguridad del tratamiento». Para una aplicación que trata datos personales, un test anual conducido siempre sobre la misma guía, con su retest, es la forma habitual de documentar ese proceso: se ve qué se probó, con qué criterio y qué pasó después de corregir.
• DORA, Reglamento (UE) 2022/2554. Se aplica a las entidades financieras desde el 17 de enero de 2025. Su art. 24 exige un programa de pruebas de resiliencia operativa digital, y el art. 26 añade, solo para las entidades designadas por la autoridad competente, pruebas guiadas por amenazas (TLPT) al menos cada tres años. Un test según la WSTG cubre la capa aplicativa del programa ordinario; el TLPT es otro encargo, con otros requisitos de proveedor, y no lo prestamos.

Ninguno de esos textos nombra la WSTG, y no hace falta que lo haga. Todos piden lo mismo: una metodología escrita, un alcance justificado, unos resultados documentados y una corrección verificada. Apoyarse en una guía pública y citar en el informe el código de cada caso de prueba es la manera más barata de tener esas cuatro cosas a la vez, y de no tener que reconstruirlas cuando llegue la auditoría.

Si lo que buscas es preparar un requisito concreto, míralo en pentesting para NIS2, en pentesting para ISO 27001 o en el artículo qué exige realmente el ENS sobre pentesting.

Enfoques: caja negra, caja gris y caja blanca

La WSTG dice qué hay que probar. El enfoque decide qué sabemos antes de empezar y, por tanto, hasta dónde llegamos con el mismo número de jornadas. En el mercado español conviven los tres; en la gran mayoría de los casos recomendamos el segundo.

Caja negra (black box)

Sin información previa: partimos de una URL, sin cuentas ni documentación, como quien no te conoce de nada. Responde bien a la pregunta «¿qué aspecto tengo visto desde internet?» y cubre con solvencia WSTG-INFO y WSTG-CONF. Su límite es mecánico: una parte grande del presupuesto se va en reconocimiento y todo lo que hay detrás de la autenticación queda fuera de alcance. En una aplicación con área privada de clientes, un test en caja negra deja fuera por construcción WSTG-ATHZ y WSTG-BUSL, es decir, justo donde se concentran los fallos que más caros salen.

Caja gris (grey box)

Contamos con un juego de cuentas —una por rol de la aplicación— y una descripción funcional somera. Es el enfoque por defecto de un pentesting web y el que proponemos salvo que haya motivo en contra. El coste del reconocimiento cae, las doce categorías de la WSTG pasan a ser todas alcanzables y el control de acceso entre roles —el fallo que más veces encontramos— se vuelve verificable. Con las mismas jornadas, la cobertura no tiene comparación con la caja negra.

Caja blanca (white box)

A lo anterior se le suman el código fuente, los esquemas de arquitectura y, si procede, acceso a los registros. Se impone en aplicaciones críticas, en componentes de pago y en tratamientos de datos de salud: permite ir del síntoma a la línea que lo causa y comprobar casos de prueba que no se pueden provocar desde fuera. Combina de forma natural con una auditoría de código fuente.

Un test en caja negra no es «más realista» que uno en caja gris: solo está peor informado. Quien ataca de verdad no tiene fecha de entrega; un proyecto la tiene siempre. El enfoque se decide al fijar el alcance y queda escrito en el presupuesto, junto con las cuentas y los accesos que te comprometes a facilitar.

Alcance y planificación

La WSTG no fija tu alcance: lo hace presupuestable. Media hora de conversación basta casi siempre para convertir una petición difusa en un número de jornadas defendible. Lo que de verdad pesa es esto:

• El número de roles. Es el primer factor de coste, muy por delante del número de pantallas: cada rol adicional multiplica las combinaciones que hay que probar en WSTG-ATHZ.
• La superficie de API. Cuántos endpoints REST, si hay esquema GraphQL, webhooks e integraciones de terceros. Una documentación OpenAPI al día reduce el reconocimiento y, con él, el precio.
• La riqueza funcional. Pagos, importación y exportación de ficheros, generación de documentos, motor de reglas, zona de administración: son las funciones que alimentan WSTG-BUSL.
• El entorno. Un entorno de preproducción representativo permite pruebas que producción no admite. Si solo hay producción, trabajamos con reglas de actuación escritas y una ventana pactada —de 9:00 a 18:00 salvo que pidas otra cosa—, avisando antes a quien opera la plataforma para que no confunda el test con un incidente.
• El acceso al código fuente, si se contempla, y los componentes excluidos de forma expresa: servicios de un proveedor de alojamiento, piezas SaaS que no controlas, pasarelas de pago de terceros y cualquier prueba capaz de destruir datos.

De ahí sale un documento de alcance escrito: objetivos, exclusiones, enfoque elegido, categorías WSTG cubiertas, cuentas que nos facilitas, ventana de ejecución, contactos para escalar un hallazgo crítico, jornadas y precio cerrado con el IVA indicado aparte. Nada empieza antes de que lo valides. Si a mitad del proyecto vemos que las jornadas se quedan cortas, te lo decimos antes de consumirlas, no en el informe.

El documento de alcance se firma junto con la autorización de pruebas. Sin esa autorización no empezamos: sin ella, el mismo trabajo sería la conducta que describen los arts. 197 bis y 264 del Código Penal.

El informe, la sesión de resultados y el retest

Estos tres entregables van siempre juntos y están incluidos en el precio. Merece la pena saber qué contiene cada uno antes de comparar presupuestos, porque es justo donde más varían unos de otros.

El informe

Se entrega en español y cifrado. Cada hallazgo ocupa una ficha con el código WSTG del caso de prueba, la puntuación CVSS, el impacto explicado en términos de tu negocio —qué dato se alcanza, cuántas cuentas afecta, qué haría falta para llegar hasta ahí—, la evidencia, los pasos para reproducirlo y una corrección concreta. Delante va la síntesis para dirección y detrás la tabla de cobertura, que es lo que convierte el informe en un documento verificable: se ve qué se probó y también qué se dejó fuera, y por qué.

La sesión de presentación de resultados

Una videollamada con quien ha hecho las pruebas. Suele durar entre una y dos horas y funciona mejor con tu equipo de desarrollo delante: la mitad de las preguntas se resuelven compartiendo pantalla y repitiendo la petición en directo. Si la dirección quiere su propia sesión más corta, la hacemos aparte. La grabación queda a tu disposición.

El retest

Cuando despliegas las correcciones, volvemos a ejecutar los casos de prueba afectados y emitimos una versión actualizada del informe que refleja el estado posterior a la corrección. Está incluido, sin coste adicional, durante los 90 días siguientes a la entrega del informe inicial. Esa segunda versión es la que suelen pedirte tu cliente, tu aseguradora o quien te audite, porque una lista de fallos sin la comprobación posterior no demuestra gran cosa.

Para qué sirve el informe, y para qué no

Sirve como evidencia técnica: alimenta la auditoría del art. 31 del RD 311/2022 en un expediente del ENS, entra en el expediente que revisa el organismo de certificación en ISO 27001 y documenta el proceso regular de pruebas del art. 32.1.d) del RGPD.

No es un certificado, y no lo presentamos como tal. Haxoris no es entidad de certificación ni está acreditada por ENAC: no expedimos certificados de conformidad con el ENS, ni el distintivo que los acompaña, ni certificados de ISO 27001. Eso lo firma un organismo de certificación acreditado, y nuestro informe es una de las evidencias que va a querer ver.

Tratamiento de datos y soberanía

Un test conducido según la WSTG genera material delicado: capturas, credenciales de prueba, extractos de datos reales y un informe que describe paso a paso cómo entrar en tu aplicación. Dónde vive ese material y bajo qué jurisdicción es una pregunta razonable de cualquier departamento de compras, y merece una respuesta concreta y no una frase de folleto.

Haxoris es una empresa establecida en la Unión Europea, con oficinas en Bratislava y en Praga. De ahí salen tres consecuencias prácticas, y las tres se pueden comprobar en el contrato antes de firmarlo:

• El RGPD se aplica de forma directa, con el mismo texto y bajo autoridades de control europeas. No hace falta una capa contractual que replique garantías: el reglamento ya rige el tratamiento.
• No hay transferencia internacional de datos en el sentido del capítulo V del RGPD, porque el tratamiento no sale del Espacio Económico Europeo. No hacen falta cláusulas contractuales tipo, ni evaluación de impacto de la transferencia, ni el análisis de derecho extranjero que sí exige contratar fuera de la Unión.
• Ninguna autoridad de un tercer país puede reclamar el material por la vía de su propio derecho interno. La discusión sobre acceso extraterritorial —la CLOUD Act estadounidense es el caso conocido— sencillamente no se plantea.

En lo operativo: el material del proyecto se cifra en reposo y en tránsito, se conserva el tiempo pactado y se destruye a petición tuya con constancia escrita. Las personas que van a tocar tu aplicación están nombradas en el contrato, con sus certificaciones, y firman confidencialidad a título individual. El informe se entrega cifrado y en español.

Si tu comité de compras nunca ha contratado seguridad ofensiva fuera de España, lo tratamos punto por punto en contratar una empresa de pentesting no española.

Qué no hacemos

Decir dónde está el límite es lo que hace creíble todo lo anterior. Estas seis cosas quedan fuera, y preferimos que lo sepas antes de pedirnos un presupuesto.

• No certificamos. Haxoris no es entidad de certificación ni está acreditada por ENAC, así que no expedimos certificados de conformidad con el ENS, ni el distintivo que los acompaña, ni certificados de ISO 27001. Eso lo firma un organismo de certificación acreditado; lo nuestro es el informe técnico que ese organismo te va a pedir como evidencia.
• No somos quien audita el ENS. La auditoría del art. 31 y la certificación del art. 38 del RD 311/2022 tienen su propio circuito de entidades habilitadas. Nuestro trabajo alimenta esa auditoría con evidencia técnica; no la sustituye. En quién puede auditar el ENS explicamos quién firma qué.
• No hacemos TLPT. Las pruebas guiadas por amenazas del art. 26 de DORA exigen proveedores que cumplan el art. 27 del Reglamento (UE) 2022/2554 y un proceso dirigido por la autoridad competente. Un ejercicio de Red Team nuestro puede servir de preparación previa, pero no lo sustituye y no nos presentamos a ese encargo.
• No trabajamos con información clasificada. El acceso a materia clasificada requiere habilitación de la Oficina Nacional de Seguridad, que no tenemos.
• La WSTG no cubre todo. Es una guía aplicativa. Una infraestructura interna, un entorno cloud o un ejercicio ofensivo completo se prueban con otra trama: los tienes en infraestructura, cloud y Red Team. Un análisis de vulnerabilidades tampoco es esto, y tampoco lo sustituye.
• No tenemos establecimiento en España. Somos un proveedor europeo: firmamos, facturamos y respondemos desde la Unión Europea, y trabajamos en español. Si tu pliego exige un proveedor establecido en España, dínoslo en la primera llamada y te lo diremos claro en lugar de hacerte perder el proceso.