El WAPT, Web Application Penetration Test, es la prueba en la que expertos en seguridad atacan una aplicación web de forma controlada para descubrir sus vulnerabilidades antes de que lo haga otro. Parece algo de grandes empresas y, en cambio, afecta a cualquiera que tenga un portal de clientes, un e-commerce, una plataforma SaaS o incluso solo un área privada en la web.

Un ejemplo que lo deja claro. Una empresa de servicios tiene un portal donde los clientes descargan facturas y contratos. La dirección de la página termina con un número, del tipo "documento=1045". Un cliente curioso prueba a cambiarlo por 1046 y se encuentra delante la factura de otro cliente. Ningún hacker sofisticado, ningún malware, solo un control de accesos que faltaba. Es una de las vulnerabilidades más extendidas que existen, y un escáner automático difícilmente la detecta, porque técnicamente la página funciona perfectamente.

El WAPT sirve para descubrir exactamente este tipo de problemas. Y desde hace un par de años tiene también un peso documental: clientes, licitaciones públicas y normativas como NIS2 y el RGPD exigen demostrar que la seguridad se ha verificado, y un informe de penetration test aplicativo es una de las pruebas más convincentes. Aquí encontrarás cómo funciona un WAPT, en qué se distingue de un vulnerability assessment, qué modalidades existen, qué comprueba a la luz del OWASP Top 10:2025 y cómo se lee el informe.

Qué es un WAPT y qué se prueba en una aplicación web

¿Qué es un WAPT? Un WAPT, o Web Application Penetration Test, es una prueba de seguridad en la que analistas especializados simulan ataques informáticos reales contra una aplicación web. El objetivo es identificar las vulnerabilidades, demostrar si pueden explotarse y cómo, e indicar cómo corregirlas, con un informe final que la empresa puede usar tanto para intervenir como en calidad de evidencia ante terceros.

El alcance de un WAPT es la aplicación en todas sus partes: la interfaz que ve el usuario, los servicios de back end, las API, los mecanismos de inicio de sesión y gestión de sesiones, el control de quién puede ver y hacer qué, el diálogo con las bases de datos. Los tipos más comunes son portales web con áreas privadas, API que conectan sistemas distintos, plataformas SaaS usadas por varios clientes, servicios online y e-commerce.

Cada uno tiene sus puntos débiles típicos. En las plataformas SaaS la pregunta clave es si los datos de un cliente permanecen realmente separados de los de los demás. En el e-commerce se mira sobre todo a pagos, carritos y cuentas. En las API el riesgo clásico es que un endpoint pensado para uso interno sea accesible desde fuera, o que devuelva más datos de los necesarios. Para las API existe además una clasificación específica de riesgos, el OWASP API Security Top 10, que un buen WAPT tiene en cuenta.

¿Por qué precisamente las aplicaciones web? Porque están expuestas por definición. Para atacar un servidor interno hay que entrar antes en la red; para atacar una aplicación web basta un navegador. Además son software vivo: se actualizan a menudo, se integran con componentes de terceros, se desarrollan con plazos ajustados. Cada versión puede abrir una brecha nueva.

WAPT, vulnerability assessment y penetration test de infraestructura: las diferencias

Estas tres actividades se confunden a menudo, y la confusión sale cara, porque lleva a creerse protegido habiendo comprobado solo una parte del problema.

El vulnerability assessment identifica y evalúa vulnerabilidades potenciales, a menudo con ayuda de escáneres automáticos: versiones de software antiguas, parches ausentes, configuraciones erróneas. Es rápido, repetible, económico y excelente como control periódico. No siempre incluye la verificación controlada de la explotabilidad y del impacto de las vulnerabilidades. Los resultados de los escáneres pueden además incluir falsos positivos, que requieren comprobación.

El WAPT profundiza en si las vulnerabilidades pueden explotarse y cómo, y qué impacto pueden tener. Los analistas usan también herramientas automáticas, pero el grueso del trabajo es manual: verifican cada fallo, lo combinan con otros para construir escenarios de ataque realistas y miden el impacto concreto. Las vulnerabilidades ligadas a la lógica de la aplicación, como el ejemplo de la factura, un carrito que acepta cantidades negativas o un flujo de pago que puede saltarse, emergen casi solo así.

El penetration test de infraestructura, por último, mira a redes, servidores, firewalls, VPN y servicios expuestos. Es complementario al WAPT: una infraestructura blindada puede alojar una aplicación llena de agujeros, y una aplicación escrita estupendamente puede estar en un servidor mal configurado. Quien expone aplicaciones críticas suele combinar ambas verificaciones.

WAPT black-box, grey-box y white-box: las tres modalidades comparadas

Las modalidades de un WAPT se distinguen por cuánta información reciben los analistas antes de empezar. Cada una simula a un atacante distinto.

El WAPT black-box: la perspectiva de quien llega desde internet

En la prueba black-box los analistas parten de cero: ninguna credencial, ninguna documentación, solo la dirección de la aplicación. Exactamente como un atacante cualquiera. Mapean la superficie expuesta, identifican los endpoints y buscan las vulnerabilidades accesibles desde fuera. Es la modalidad que responde a la pregunta más instintiva: ¿qué ve y qué puede hacer quien encuentra mi aplicación en internet?

El WAPT grey-box: qué ocurre después del login

En grey-box los analistas reciben las credenciales de uno o más usuarios, por ejemplo un usuario estándar y un administrador. Aquí se explora la parte de la aplicación que está detrás del login, que suele ser donde se esconden los problemas más graves. El foco es el control de accesos. ¿Un usuario estándar consigue entrar en las funciones de administrador? ¿Consigue leer o modificar los datos de otro usuario? En la jerga se habla de privilege escalation vertical en el primer caso y horizontal en el segundo, y están entre las causas más frecuentes de brechas de datos.

El WAPT white-box: la prueba con todas las cartas sobre la mesa

En white-box los analistas tienen acceso completo al código fuente, la documentación y la arquitectura. Es la modalidad más profunda y se acerca a una revisión de código orientada a la seguridad. Requiere más tiempo y más implicación del equipo de desarrollo. Para la mayoría de las pymes la combinación de black-box y grey-box ofrece el mejor equilibrio entre cobertura del riesgo, plazos y costes, y el white-box se reserva a aplicaciones especialmente críticas o a fases concretas del desarrollo.

Las fases de un Web Application Penetration Test

Un WAPT bien hecho sigue un recorrido de cinco fases, precedido por un paso preliminar que a menudo se subestima.

El paso preliminar es la definición del alcance y de las reglas de compromiso. Empresa y analistas acuerdan qué aplicaciones probar, en qué entornos, con qué tipos de usuarios, en qué ventana temporal, con qué límites y con qué canales de comunicación en caso de problemas. Hace falta también una autorización escrita: atacar un sistema informático sin el consentimiento del titular es un delito, y el documento de autorización protege a ambas partes. Si la aplicación está alojada por un proveedor, conviene verificar que sus condiciones permitan la prueba.

Después se empieza. La primera fase es la recopilación de información: los analistas estudian la aplicación, entienden su funcionamiento y mapean arquitectura, flujos de usuario, API y tecnologías empleadas. La segunda es la identificación de vulnerabilidades, con herramientas automáticas y análisis manual que se complementan. La tercera es la exploración en profundidad de la aplicación, donde se someten a presión autenticación, sesiones, permisos y gestión de entradas. La cuarta es la explotación, el intento controlado de aprovechar los fallos detectados para demostrar su gravedad real. La quinta es el informe, que lo documenta todo e indica cómo intervenir.

Una nota práctica sobre el entorno de prueba. Cuando existe un entorno de staging idéntico al de producción, es el mejor lugar para las pruebas más invasivas. Si se prueba en producción, conviene programar el trabajo en horarios de bajo tráfico, tener una copia de seguridad reciente y avisar a quien monitoriza los sistemas, para evitar que la prueba se confunda con un ataque real.

OWASP Top 10:2025: las vulnerabilidades que busca un WAPT

¿Qué es el OWASP Top 10? Es la clasificación de los diez riesgos de seguridad más críticos para las aplicaciones web, publicada por la fundación OWASP. Es la referencia internacional más utilizada para clasificar vulnerabilidades en los informes de penetration test y en los cuestionarios de seguridad de proveedores. La edición 2025, presentada en noviembre de 2025 y consolidada en enero de 2026, es la primera actualización desde 2021.

En lo alto de la lista sigue el control de accesos deficiente, Broken Access Control, que en la edición 2025 engloba también el Server-Side Request Forgery. Es la categoría del ejemplo de la factura: permisos ausentes o sorteables. En segundo lugar han subido las configuraciones de seguridad erróneas, que en 2021 eran quintas, y el motivo es intuitivo: las aplicaciones modernas dependen cada vez más de configuraciones de nube, contenedores y servicios externos.

En tercer lugar está una de las dos novedades, las deficiencias en la cadena de suministro del software. Amplía la antigua categoría de componentes vulnerables y obsoletos hasta incluir dependencias, sistemas de build e infraestructuras de distribución. Para quien desarrolla con decenas de librerías de código abierto es un tema nada teórico.

Siguen los fallos criptográficos en cuarto lugar y las injection en quinto, una familia que va desde la SQL injection hasta el cross-site scripting. En sexto el diseño inseguro, en séptimo los fallos de autenticación, en octavo las deficiencias de integridad del software y los datos, en noveno las deficiencias de registro y alerta. Cierra la segunda novedad de la edición 2025, la gestión inadecuada de las condiciones excepcionales: aplicaciones que ante un error imprevisto se comportan de forma insegura, por ejemplo mostrando detalles técnicos o dejando una transacción a medias.

¿Por qué importa que el informe siga esta clasificación? Porque todos la leen igual: el equipo de desarrollo, el proveedor externo, el responsable de seguridad del cliente, el auditor. Un informe alineado con el OWASP Top 10 encaja sin fricciones en los procesos de cualificación de proveedores.

El Top 10 ayuda a clasificar los riesgos, pero no agota las verificaciones de un WAPT: la prueba debe considerar también las funciones y los riesgos específicos de la aplicación.

Cuándo pedir un WAPT: los momentos en que más rinde

El WAPT da lo máximo cuando se vincula a momentos precisos de la vida de una aplicación o de la empresa.

Antes del lanzamiento es el momento ideal. Ningún dato de clientes está todavía expuesto, las correcciones se insertan en el ciclo de desarrollo y cuestan mucho menos. Después de cada cambio importante es el segundo momento clave, porque una nueva funcionalidad o una integración pueden abrir una brecha que antes no existía. En estos casos la prueba puede centrarse en las partes afectadas, con plazos y costes reducidos.

Luego están las ocasiones comerciales. Muchas licitaciones públicas piden evidencias de pruebas de seguridad sobre las aplicaciones implicadas en el suministro, y cada vez más clientes privados quieren un informe antes de confiar sus datos a un proveedor. En ambos casos un informe WAPT reciente, con vulnerabilidades descritas por categoría, gravedad y estado de las correcciones, es un anexo listo que ahorra semanas en la cualificación.

Tras un incidente, la prioridad es contener el ataque y reconstruir lo ocurrido mediante actividades de respuesta a incidentes y análisis forense. Después, un WAPT específico puede ayudar a verificar las vulnerabilidades y las correcciones aplicadas.

¿Cada cuánto repetirlo? Una buena regla es al menos una vez al año en las aplicaciones críticas y, en todo caso, tras cada versión importante. Quien publica versiones muy a menudo hace bien en integrar pruebas más ligeras en el ciclo de desarrollo y reservar el WAPT completo para las versiones principales.

WAPT y cumplimiento: el papel del penetration test en NIS2, RGPD e ISO 27001

El WAPT nace como actividad técnica, pero hoy tiene un papel preciso también en el cumplimiento normativo. Las principales normas sobre seguridad y datos exigen demostrar que las medidas adoptadas funcionan, y el penetration test es una de las pruebas más sólidas.

El RGPD, en su artículo 32, exige a responsables y encargados del tratamiento medidas técnicas y organizativas adecuadas y, entre ellas, un procedimiento para probar, verificar y evaluar regularmente su eficacia. Un WAPT periódico puede contribuir a las verificaciones previstas por el artículo 32, cuando resulte apropiado respecto a los riesgos del tratamiento. El informe documenta las pruebas realizadas y debe valorarse junto con las medidas adoptadas y las correcciones aplicadas.

La NIS2, traspuesta en Italia mediante el D.Lgs. 138/2024, exige a las entidades esenciales e importantes medidas de gestión del riesgo que incluyen la gestión de vulnerabilidades y la evaluación de la eficacia de las medidas de seguridad. Para muchas entidades incluidas en la lista NIS en 2025, el plazo para adoptar las medidas de seguridad básicas vence en octubre de 2026, según el calendario vinculado a la comunicación recibida de la ACN. Un informe WAPT, acompañado de las correcciones y del retest, puede ser una evidencia útil para documentar las verificaciones realizadas.

La ISO 27001:2022 incluye entre los controles del Anexo A la gestión de las vulnerabilidades técnicas y las pruebas de seguridad durante el desarrollo y la aceptación de los sistemas. En una auditoría, un informe WAPT acompañado del plan de corrección y del retest documenta de forma muy convincente la eficacia de esos controles.

El informe WAPT: cómo está hecho y cómo usarlo

El informe es el verdadero producto del WAPT: habla a dos públicos distintos y lo hace en dos partes.

El resumen ejecutivo es para la dirección: nivel de riesgo global, vulnerabilidades más graves, prioridades de intervención, en un lenguaje que se entiende sin ser técnico. El capítulo técnico es para quien debe corregir: para cada vulnerabilidad describe los activos implicados, la categoría OWASP pertinente y la gravedad de la vulnerabilidad, eventualmente acompañada de una puntuación CVSS, la demostración de la explotabilidad con los pasos para reproducirla y las indicaciones operativas para resolverla.

El informe, sin embargo, vale cuando los fallos se cierran. Conviene empezar por las vulnerabilidades más graves y más fáciles de explotar, asignar un responsable y un plazo a cada una y hacer seguimiento del avance. Una vez completadas las correcciones, el retest verifica que las mitigaciones funcionen y produce un nuevo informe. A los clientes y en las licitaciones suele ser este segundo documento el más solicitado, porque demuestra el ciclo completo: problema encontrado, problema resuelto, solución verificada.

Nuestro WAPT: cómo probamos las aplicaciones de las pymes

Hemos pensado nuestro servicio WAPT para las empresas que no tienen un equipo de seguridad interno y necesitan dos cosas muy concretas: saber dónde meter mano y tener un informe que mostrar a clientes y organismos contratantes.

Ponemos a prueba portales web, API, plataformas SaaS, servicios online y e-commerce, es decir las aplicaciones donde un fallo se traduce de inmediato en accesos indebidos, datos de clientes expuestos, fraudes o transacciones comprometidas. Trabajamos en dos modalidades. Con el black-box miramos tu aplicación con los ojos de quien llega desde internet sin credenciales y te decimos qué consigue descubrir. Con el grey-box entramos con las credenciales de un usuario estándar y verificamos si ese rol logra ir más allá de los permisos que debería tener, identificando los riesgos de privilege escalation e indicándote con precisión dónde intervenir.

El alcance lo construimos contigo, en función de cuántas plataformas quieras incluir y cuántos tipos de usuario haya que verificar: cada rol, del administrador al invitado, se prueba por separado. El trabajo se desarrolla íntegramente en remoto, con la misma profundidad que una prueba presencial, y un experto dedicado lo acompaña desde el primer intercambio de información hasta la entrega. Nos comprometemos a entregarte el informe en 10-12 días laborables por aplicación, desde la disponibilidad de la información y de los accesos necesarios para la prueba.

Lo que recibes es un informe técnico completo: un resumen ejecutivo para tener enseguida el panorama general y una parte técnica con los activos implicados, las vulnerabilidades asociadas a las categorías del OWASP Top 10, la valoración de su gravedad e indicaciones operativas para la corrección. Si quieres, después de aplicar las correcciones realizamos un retest sobre las vulnerabilidades corregidas y te entregamos un informe que documenta el resultado de las verificaciones. Y dado que el WAPT es también una pieza de NIS2, RGPD e ISO 27001, nuestros Lead Auditors pueden conectar los resultados con tu itinerario de cumplimiento. Es una combinación frecuente en las empresas del sector IT y software.

¿Quieres saber cómo de sólida es tu aplicación? Escríbenos para solicitar el WAPT y definir juntos el alcance.

Preguntas frecuentes sobre el WAPT

¿Qué es un WAPT en palabras sencillas?

Es una prueba en la que expertos en seguridad atacan tu aplicación web de forma controlada, con tu permiso, para encontrar los fallos antes que un atacante real. Al final recibes un informe que explica qué han encontrado, cómo de grave es y cómo arreglarlo. Es la forma más directa de saber cómo de segura es una aplicación en el mundo real.

¿Qué diferencia hay entre WAPT black-box y grey-box?

En black-box los analistas parten sin credenciales y simulan un atacante externo. En grey-box reciben las credenciales de uno o más usuarios y verifican qué ocurre después del login, por ejemplo si un usuario consigue ver datos de otros o usar funciones reservadas. Las dos modalidades se complementan, y juntas cubren la mayor parte de los riesgos de una aplicación.

¿Cuánto dura un WAPT?

Depende de cuántas aplicaciones y cuántos roles de usuario entren en el alcance y de lo compleja que sea la aplicación. En nuestro servicio entregamos el informe en 10–12 días laborables por aplicación, desde la disponibilidad de la información y de los accesos necesarios para la prueba. El trabajo se desarrolla íntegramente en remoto.

¿Cada cuánto hay que hacer un WAPT?

Una buena práctica es al menos una vez al año en las aplicaciones importantes y después de cada cambio relevante, como nuevas funcionalidades, cambios de arquitectura o nuevas integraciones. Algunos clientes y licitaciones piden informes con fecha reciente, y vale la pena tenerlo en cuenta en la planificación.

¿Un WAPT puede tumbar la aplicación?

Un WAPT profesional sigue reglas de compromiso acordadas sobre entornos, horarios y límites. Los analistas usan técnicas controladas para demostrar las vulnerabilidades limitando el impacto en la operativa. Cuando existe un entorno de staging idéntico al de producción, las pruebas más invasivas se hacen allí. Una copia de seguridad reciente y un aviso a quien monitoriza los sistemas completan la preparación.

¿El WAPT es obligatorio para la NIS2?

La NIS2 exige medidas de gestión del riesgo que comprenden la gestión de vulnerabilidades y la verificación de la eficacia de las medidas de seguridad, dejando a la empresa la elección de las herramientas. El WAPT es una de las formas más eficaces de demostrarlo en las aplicaciones web expuestas, y un informe con las remediaciones es una evidencia sólida ante una comprobación de la ACN o una petición de un cliente.

¿Qué es el OWASP Top 10:2025?

Es la clasificación actualizada de los diez riesgos más críticos para las aplicaciones web, publicada por la fundación OWASP. En primer lugar está el control de accesos deficiente, y entre las novedades figuran las deficiencias en la cadena de suministro del software y la gestión inadecuada de las condiciones excepcionales. Es el estándar más utilizado para clasificar vulnerabilidades en los informes de penetration test.

¿Qué ocurre después de la entrega del informe?

Tu equipo de desarrollo, o el proveedor que construyó la aplicación, corrige las vulnerabilidades siguiendo las prioridades e indicaciones del informe. Después puedes pedir el retest, que verifica las correcciones y produce un nuevo informe. Ese segundo documento indica si las vulnerabilidades sometidas a retest resultan resueltas, y suele ser el que clientes y organismos contratantes quieren ver.