Si su aplicación web gestiona inicios de sesión, pagos o datos de clientes, tarde o temprano alguien le pedirá que demuestre que es segura: el cuestionario de seguridad de un comprador empresarial, un auditor o su propio consejo de administración después de que una brecha en su sector salga en las noticias. Una respuesta creíble empieza por saber en qué consisten realmente las pruebas de seguridad de aplicaciones web y qué partes de ellas está pagando cuando las realiza con su propio equipo o recurre a servicios de pruebas de seguridad.
Las pruebas de seguridad de aplicaciones web detectan debilidades explotables en una aplicación web antes de que lo hagan los atacantes. Combinan cuatro enfoques: el análisis estático del código fuente (SAST), las pruebas dinámicas de la aplicación en ejecución desde el exterior (DAST), las pruebas instrumentadas desde dentro de la aplicación en tiempo de ejecución (IAST) y las pruebas de penetración manuales. Cada uno detecta un tipo distinto de fallo, por lo que un programa eficaz utiliza varios de ellos.
La principal decisión de coste es el orden. Una vez configurados, los escaneos automatizados de SAST y DAST cuestan poco por ejecución y pueden lanzarse en cada compilación o cada noche. Una prueba de penetración manual de una aplicación web de tamaño medio suele requerir de una a tres semanas de trabajo de un especialista, lo que la convierte en la capa cara y en la que conviene planificar con cuidado. Equivocarse en el orden suele significar pagar a expertos en pruebas de penetración para que encuentren problemas que un escáner gratuito habría detectado.
A continuación: qué hace cada enfoque, dónde se queda corto y cuándo necesita cada uno.
Los 4 enfoques de prueba: SAST, DAST, IAST y pruebas de penetración
Los cuatro enfoques se diferencian en qué analizan y en qué momento se ejecutan. SAST revisa el código antes de que llegue a producción, DAST e IAST prueban la aplicación mientras se ejecuta, y las pruebas de penetración la enfrentan a un atacante humano. Cada uno tiene puntos ciegos que los demás cubren, y por eso los programas maduros aplican los cuatro en distintos momentos del ciclo de lanzamiento.
Pruebas estáticas de seguridad de aplicaciones (SAST)
SAST analiza el código fuente, el bytecode o los binarios sin ejecutar la aplicación. Rastrea cómo fluyen los datos desde la entrada del usuario hasta las operaciones sensibles y señala patrones como entradas sin sanear que llegan a una consulta de base de datos, secretos incrustados en el código y criptografía débil. Puede ejecutarse en el IDE del desarrollador o en cada pull request, e indica el archivo y la línea exactos.
Su límite es el contexto. SAST no puede ver cómo está configurada o desplegada la aplicación y a menudo señala rutas de código que en la práctica son inalcanzables, por lo que el primer escaneo de una base de código existente suele generar una larga lista que alguien tiene que revisar y priorizar.
El análisis de composición de software (SCA) suele ejecutarse junto con SAST y comprueba si las bibliotecas de terceros tienen vulnerabilidades conocidas, el riesgo que hay detrás de los componentes vulnerables y obsoletos.
Pruebas dinámicas de seguridad de aplicaciones (DAST)
DAST prueba la aplicación en ejecución desde fuera, como lo haría un atacante, sin acceso al código. Un escáner rastrea la aplicación, envía peticiones manipuladas a cada entrada que encuentra y analiza las respuestas en busca de indicios de inyección, cross-site scripting (XSS), cabeceras de seguridad ausentes, archivos expuestos y servidores mal configurados.
DAST detecta problemas que solo existen una vez desplegada la aplicación: la configuración del servidor y de TLS, los atributos de las cookies, las páginas de error que revelan trazas de pila. Es más débil en todo aquello a lo que un rastreador no llega, como páginas protegidas por una autenticación de varios pasos o rutas de aplicaciones de una sola página que solo aparecen después de que se ejecuta JavaScript. Cuando encuentra un problema, informa de una URL, y los desarrolladores todavía tienen que localizar el código.
Pruebas interactivas de seguridad de aplicaciones (IAST)
IAST coloca un agente dentro de la aplicación en ejecución, en el entorno de ejecución del lenguaje o en el servidor de aplicaciones, y observa lo que hace el código mientras se utiliza la aplicación. Cuando una petición de prueba lleva una entrada hasta una consulta SQL o una ruta de archivo, el agente ve tanto la petición como la línea exacta de código que la procesó.
Así combina la visión en tiempo de ejecución de DAST con la precisión a nivel de código de SAST, normalmente con menos falsos positivos que cualquiera de los dos. El inconveniente es la cobertura: IAST solo analiza las rutas de código que algo ejecuta realmente, por lo que su valor depende de la calidad de las pruebas funcionales y de regresión que ponen en marcha la aplicación. Además, necesita un agente compatible con su lenguaje y su framework, y añade cierta sobrecarga al entorno de pruebas en el que se ejecuta.
Pruebas de penetración manuales
Una prueba de penetración consiste en que un especialista en seguridad intenta activamente vulnerar la aplicación con los objetivos de un atacante real: leer los datos de otro cliente, convertir una cuenta normal en una de administrador o saltarse un paso de pago. Los testers usan escáneres para ganar cobertura y después dedican la mayor parte de su tiempo a lo que las herramientas no pueden juzgar, como encadenar dos hallazgos de baja gravedad para convertirlos en uno grave, o abusar de un flujo de trabajo técnicamente válido que nunca debió permitirse.
De los cuatro enfoques, las pruebas de penetración son las que detectan de forma fiable los fallos de autorización y el abuso de la lógica de negocio, y generan evidencias que un comprador o un auditor aceptará. También son una instantánea de un momento concreto y la capa más cara por hallazgo. Según cuánto sepa el tester de antemano, una prueba de penetración se plantea como un proyecto de caja negra, caja gris o caja blanca, que es como QAwerk estructura sus servicios de pruebas de penetración.
SAST vs. DAST vs. IAST vs. pruebas de penetración de un vistazo
Qué examina
El código fuente, sin ejecutarlo
La aplicación en ejecución, desde fuera
La aplicación en ejecución, desde dentro mediante un agente
La aplicación en ejecución, atacada por una persona
Cuándo se ejecuta
En cada commit o pull request
Cada noche o en cada versión, contra staging
Durante las ejecuciones de pruebas automatizadas y funcionales
Antes de versiones importantes, tras grandes cambios, al menos una vez al año
Detecta bien
Código propenso a inyecciones, secretos incrustados, criptografía débil
Configuraciones erróneas, cabeceras ausentes, XSS reflejado, archivos expuestos
Fallos de inyección y de flujo de datos, con la línea exacta de código
Control de acceso roto, abuso de la lógica de negocio, exploits encadenados
Pasa por alto
Problemas de ejecución y de configuración
Ubicación en el código, fallos de lógica, páginas difíciles de rastrear
Rutas de código que ninguna prueba ejecuta
Todo lo que quede fuera del alcance y el tiempo acordados
Falsos positivos
Altos
Medios
Bajos
Muy bajos, los hallazgos se verifican manualmente
Quién actúa sobre los resultados
Desarrolladores
DevOps y desarrolladores
Desarrolladores y QA
Responsables de ingeniería, seguridad, cumplimiento normativo
Cómo se complementan estos enfoques
SAST detecta los problemas antes que nadie, cuando la corrección es un cambio de una línea en una rama sin fusionar, lo que lo convierte en la capa más barata sobre la que actuar. SAST no puede decirle si una línea señalada es alcanzable ni si el servidor desplegado está configurado de forma segura.
DAST e IAST recogen lo que solo aparece en tiempo de ejecución. DAST comprueba la aplicación tal como está desplegada, incluidos el servidor web, la configuración de TLS y las cabeceras de respuesta. IAST confirma qué problemas de flujo de datos son reales observándolos mientras ocurren, y por eso encaja bien con una suite de regresión automatizada ya existente: las pruebas que ya verifican funcionalidades empiezan a verificar también la seguridad.
Las pruebas de penetración manuales cubren el tipo de fallo que peor gestiona la automatización. Un escáner puede confirmar que un endpoint exige iniciar sesión. Lo que no puede es darse cuenta de que un cliente con la sesión iniciada puede cambiar el ID de un pedido en la URL y ver la factura de otra persona. El control de acceso roto de este tipo ocupa el primer puesto del OWASP Top 10:2025, y encontrarlo requiere a una persona que entienda qué debe permitir la aplicación. Para ver cómo es la capa manual área por área, consulte nuestra lista de verificación de pruebas de penetración de aplicaciones web.
La metodología de pruebas de OWASP
El Open Worldwide Application Security Project (OWASP) publica la Web Security Testing Guide (WSTG), el estándar de referencia más citado sobre cómo probar la seguridad de una aplicación web. Su versión estable actual, la 4.2, organiza las pruebas activas en 12 categorías:
- Recopilación de información
- Pruebas de gestión de la configuración y del despliegue
- Pruebas de gestión de identidades
- Pruebas de autenticación
- Pruebas de autorización
- Pruebas de gestión de sesiones
- Pruebas de validación de entradas
- Pruebas de gestión de errores
- Pruebas de criptografía débil
- Pruebas de lógica de negocio
- Pruebas del lado del cliente
- Pruebas de API
Cada categoría contiene casos de prueba numerados. Las pruebas de gestión de sesiones, por ejemplo, abarcan los atributos de las cookies, la fijación de sesión, la falsificación de peticiones entre sitios, el comportamiento al cerrar sesión y la expiración de la sesión. Los informes profesionales de pruebas de penetración suelen citar estos identificadores (WSTG-SESS-05 es la prueba de falsificación de peticiones entre sitios), de modo que cada hallazgo remite a un procedimiento documentado.
Una forma práctica de asignar las categorías de la WSTG a los cuatro enfoques:
- Recopilación de información, configuración y pruebas del lado del cliente: en gran parte automatizables con DAST, con una persona que revise lo que señala el escáner.
- Validación de entradas y criptografía débil: bien cubiertas por SAST en el código y por DAST o IAST en tiempo de ejecución.
- Autenticación y gestión de sesiones: parcialmente automatizables, pero el bloqueo de cuentas, el restablecimiento de contraseñas y la expiración de sesiones requieren que un tester recorra los flujos paso a paso.
- Autorización y lógica de negocio: casi por completo pruebas de penetración manuales.
Su estándar complementario, el Application Security Verification Standard (ASVS) de OWASP, define requisitos de seguridad en tres niveles de rigor, lo que le ayuda a decidir con qué profundidad deben realizarse las pruebas de su aplicación.
Cómo crear un programa de pruebas de seguridad de aplicaciones web
Un programa de pruebas sigue el ciclo de vida de desarrollo de software (SDLC). El Secure Software Development Framework, SP 800-218 del Instituto Nacional de Estándares y Tecnología de EE. UU. (NIST) recoge como dos prácticas separadas la revisión del código legible por humanos en busca de vulnerabilidades (práctica PW.7) y las pruebas del código ejecutable (práctica PW.8).
Codificación
SAST en el IDE y en las pull requests, más SCA para las dependencias
En cada cambio
CI y staging
DAST contra staging, agente IAST durante la ejecución de la regresión automatizada
Cada noche o en cada versión candidata
Prelanzamiento
Prueba de penetración manual centrada en funciones nuevas o modificadas, sobre todo inicio de sesión, pagos y roles de usuario
Antes de cada versión importante
Producción
Prueba de penetración externa de la aplicación en producción, más escaneos DAST ligeros
Al menos una vez al año y tras cambios significativos
Bloquee las fusiones solo ante hallazgos de SAST de gravedad alta, o los desarrolladores aprenderán a ignorar la herramienta, y verifique de nuevo las correcciones después de cada prueba de penetración, porque una corrección sin verificar sigue siendo un hallazgo abierto.
En cuanto a la frecuencia, la mayoría de los equipos empiezan con una prueba de penetración anual más una nueva verificación tras las correcciones. Para las aplicaciones que almacenan, procesan o transmiten datos de tarjetas, PCI DSS exige pruebas de penetración al menos una vez cada 12 meses y después de cualquier cambio significativo. Los productos de fintech, healthtech o cualquiera que guarde documentos de identidad suelen hacer pruebas con más frecuencia. Nuestra guía sobre la frecuencia de las pruebas de penetración explica cómo fijar esa cadencia según su perfil de riesgo.
Si parte de cero, este orden le da la mayor cobertura con el menor gasto:
- Active SAST y el escaneo de dependencias en el repositorio.
- Añada un escaneo DAST contra su entorno de staging.
- Reserve una prueba de penetración con un alcance definido antes de su próxima versión importante o revisión de seguridad.
- Añada IAST cuando tenga una suite de regresión automatizada que merezca la pena instrumentar.
Si necesita justificar internamente el presupuesto de ese tercer paso, aquí le explicamos por qué las pruebas de penetración son importantes para un producto en su etapa.
Cuándo basta con una configuración más ligera
No todas las aplicaciones necesitan las cuatro capas. Un sitio de marketing sin inicio de sesión, sin datos de clientes almacenados y con un único formulario de contacto necesita un escaneo DAST, una configuración de servidor reforzada y actualizaciones periódicas de dependencias, y ahí una prueba de penetración completa aporta poco valor. Conviene posponer IAST hasta tener una buena cobertura de pruebas automatizadas, porque un agente que observa tres pruebas de humo analiza muy poco. Una prueba de penetración sobre una aplicación que nadie ha escaneado todavía gasta horas caras en hallazgos que una herramienta gratuita habría señalado.
La combinación completa compensa su coste en cualquier aplicación con varios roles de usuario, pagos, datos personales o regulados, o clientes empresariales que envían cuestionarios de seguridad.
Cómo realiza QAwerk las pruebas de seguridad de aplicaciones web
En QAwerk, las pruebas de seguridad las realiza el mismo equipo que se encarga de las pruebas funcionales y de las pruebas de regresión. Los ingenieros de QA que crean la suite de regresión saben qué flujos importan, así que las ejecuciones de DAST e IAST cubren los recorridos que siguen los usuarios reales, y los especialistas en pruebas de penetración empiezan con los roles y las reglas de negocio ya mapeados. Un responsable de validación reproduce cada hallazgo y lo documenta con pasos y evidencias, para que los desarrolladores puedan abordarlo en el siguiente sprint.
Nos incorporamos en la etapa en la que se encuentre el producto, desde una aplicación previa al lanzamiento que necesita su primera prueba de penetración hasta un producto en producción que afronta su primera revisión de seguridad por parte de un cliente empresarial. Los proyectos abarcan la revisión de código con SAST y las pruebas de penetración de caja negra, gris o blanca, con precios basados en estimaciones Time & Material que incluyen un rango realista y otro pesimista para cada tarea. QAwerk ha realizado pruebas de penetración para productos fintech y de verificación de identidad, donde la autorización y la gestión de sesiones reciben el examen más minucioso.
Combine pruebas estáticas, dinámicas y manuales
Ningún enfoque de pruebas lo detecta todo por sí solo. SAST mantiene fuera el código defectuoso desde el principio, DAST e IAST muestran lo que ocurre en tiempo de ejecución, y las pruebas de penetración manuales encuentran los fallos de acceso y de lógica que la automatización pasa por alto. Un programa real de seguridad de aplicaciones web ejecuta cada uno de ellos en su propio momento del SDLC. Si quiere que un solo equipo lo planifique y lo ejecute, hable con nosotros sobre la seguridad de su aplicación web a través de nuestros servicios de pruebas de aplicaciones web.
Preguntas frecuentes
¿Cuál es la diferencia entre SAST y DAST?
SAST analiza el código fuente sin ejecutarlo y señala la línea exacta de un fallo, por lo que se ejecuta pronto, en cada commit. DAST prueba la aplicación en ejecución desde fuera y detecta problemas de configuración y de tiempo de ejecución, por lo que necesita una versión desplegada. Detectan problemas distintos, y la mayoría de los equipos utilizan ambos.
¿Es IAST un sustituto de DAST?
IAST es más preciso, pero solo ve las rutas de código que ejecutan sus pruebas y necesita un agente compatible con su stack tecnológico. DAST sigue comprobando el servidor web desplegado, la configuración de TLS y las cabeceras, así que los dos funcionan mejor juntos.
¿Pueden los escáneres automatizados sustituir a una prueba de penetración?
No. Los escáneres son buenos detectando patrones conocidos, como la inyección y las configuraciones erróneas. No pueden juzgar si un usuario debería poder ver un registro o saltarse un paso de un flujo de trabajo, que es justo donde se encuentran el control de acceso roto y los fallos de lógica de negocio. Encontrarlos requiere un tester humano.
¿Con qué frecuencia deben realizarse pruebas de seguridad en una aplicación web?
Ejecute SAST y el escaneo de dependencias en cada cambio, DAST al menos una vez por versión y una prueba de penetración manual al menos una vez al año y tras cambios significativos. Las aplicaciones que gestionan pagos, datos de salud o documentos de identidad suelen necesitar pruebas de penetración con más frecuencia.
¿Qué es la metodología de pruebas de OWASP?
Es el enfoque que establece la OWASP Web Security Testing Guide, que agrupa las pruebas de seguridad de aplicaciones web en 12 categorías, desde la recopilación de información y las pruebas de autenticación hasta la gestión de sesiones, la validación de entradas y la lógica de negocio. Los testers citan sus identificadores de prueba en sus informes.
Vea una muestra de nuestra revisión del código de seguridad de una plataforma de comercio electrónico con sede en EE. UU.
