En el módulo anterior cerramos SAMM señalando que varias mejoras del roadmap de BazarNube (las prácticas de Security Testing y Secure Build) no se sostienen solo con estrategia: exigen ejecutar pruebas de seguridad reales sobre la aplicación en marcha. Ese "¿con qué lo hacemos?" tiene un nombre concreto en el mundo del código abierto: OWASP ZAP. Con esta lección pasamos de la estrategia (Top Ten, ASVS, SAMM) a la herramienta que nos deja confirmar y descubrir vulnerabilidades de forma dinámica, mientras la app corre en staging. En este primer capítulo entenderás qué es ZAP, cómo está construido por dentro y qué papel juega dentro del flujo de aseguramiento de BazarNube.

1. Qué es ZAP y de dónde viene
2. ZAP como proxy de interceptación y como DAST
3. Arquitectura y componentes clave
4. Escaneo pasivo frente a escaneo activo
5. Los modos de ZAP (safe, protected, standard, attack)
6. Casos de uso habituales
7. Cómo encaja ZAP en el flujo de BazarNube
8. Nota ético-legal

ZAP son las siglas de Zed Attack Proxy. Es una herramienta gratuita y de código abierto para encontrar vulnerabilidades de seguridad en aplicaciones y APIs web mientras se ejecutan. Es, con diferencia, el escáner dinámico (DAST) libre más usado del mundo.

Un apunte sobre su gobierno, porque genera confusión:

• Nació y creció durante años como proyecto insignia (flagship) de OWASP.
• En 2023 el proyecto se trasladó a la fundación Software Security Project (SSP), donde continúa su desarrollo. Por eso encontrarás documentación que lo llama "OWASP ZAP" y documentación más reciente que lo llama solo "ZAP".
• A efectos prácticos para BazarNube da igual el paraguas organizativo: la herramienta, el binario y la comunidad son los mismos. En este curso lo llamaremos ZAP.

Recuerda lo que vimos en M2: ZAP es DAST (Dynamic Application Security Testing). Prueba la aplicación en ejecución, desde fuera, como lo haría un atacante, sin necesidad de ver el código fuente. Es complementario a SAST (analiza el código estático) y a SCA (analiza dependencias). No compiten: se combinan.

ZAP tiene dos caras que conviene no mezclar:

La clave es que todo pasa por el proxy. ZAP no adivina la estructura de la app: aprende de las peticiones que lo atraviesan. Cuanto mejor "vea" tu tráfico (navegación manual + spiders), mejores serán sus resultados.

Por dentro, ZAP es un conjunto de piezas que colaboran. Conocerlas te ayuda a interpretar la GUI y, más adelante, a automatizar.

• Proxy de interceptación: el corazón. Captura todo el tráfico HTTP(S). Permite pausar peticiones (breakpoints) y editarlas antes de enviarlas.
• Sites tree (árbol de sitios): el mapa jerárquico de todo lo que ZAP ha visto de BazarNube (dominios, rutas, endpoints, parámetros). Es la fuente sobre la que operan los escáneres.
• Spider tradicional: rastrea la app siguiendo enlaces del HTML. Rápido, pero se pierde con contenido generado por JavaScript.
• AJAX Spider: controla un navegador real (headless) para rastrear aplicaciones de una sola página (SPA). Imprescindible para el frontend React de BazarNube, donde muchas rutas no existen hasta que el JS las genera.
• Escáner pasivo: observa el tráfico que ya ha pasado por el proxy y detecta problemas sin enviar nada nuevo (cabeceras de seguridad ausentes, cookies sin flags, fugas de información). Es seguro por naturaleza.
• Escáner activo: inyecta payloads (SQLi, XSS, path traversal...) contra los parámetros descubiertos y observa la respuesta. Es intrusivo.
• Alertas: cada hallazgo, clasificado por riesgo (Alto/Medio/Bajo/Informativo) y confianza.
• Add-ons (Marketplace): ZAP es modular; casi toda la funcionalidad avanzada (AJAX Spider, reglas de escaneo, formatos de informe, el Automation Framework) llega como complementos actualizables.

Esta distinción es la más importante de toda la lección, porque marca qué es seguro lanzar y qué no.

Regla mental para BazarNube: el pasivo puedes tenerlo siempre encendido; el activo solo se lanza contra el staging propio y con conocimiento del equipo.

ZAP tiene un interruptor global que limita lo que puede hacer. Es tu red de seguridad para no atacar por error algo que no debes.

Consejo: al empezar con BazarNube trabaja en Protected con un scope bien definido (lo veremos en 06-02). Así, aunque el spider descubra un enlace externo (por ejemplo una pasarela de pago de terceros), ZAP no la atacará.

• Exploración manual asistida: navegas BazarNube con el proxy puesto y ZAP va detectando problemas pasivamente mientras usas la web.
• Escaneo automático de una URL o de una API (con su definición OpenAPI/Swagger).
• Pruebas de APIs: importas la especificación OpenAPI del backend Node/Express y ZAP conoce todos los endpoints sin necesidad de spider.
• Regresión de seguridad en CI/CD: cada despliegue lanza un baseline scan (lo veremos en 06-04).
• Confirmar hallazgos concretos: un pentester reportó un IDOR; usas ZAP para reproducirlo de forma controlada.

Recuerda el hilo del curso. En M3 el Top Ten nos dio hallazgos concretos en BazarNube: un IDOR en /api/orders/{id}, SQLi en un buscador, XSS en las reseñas de producto, cabeceras de seguridad ausentes, un endpoint legacy Java con riesgo de XXE, y una función de importación con pinta de SSRF. En M4 convertimos parte de eso en requisitos verificables de ASVS. En M5 SAMM nos dijo organizativamente que había que hacer Security Testing.

ZAP es la pieza que cierra el bucle: coge esos hallazgos teóricos y los verifica dinámicamente en el staging de BazarNube.

Lucía (backend) quiere confirmar si el SQLi del buscador sigue vivo tras un parche. Marc (frontend) quiere saber si el XSS de reseñas se dispara con el nuevo sanitizador. La SRE quiere que todo esto corra solo en cada despliegue a staging. ZAP responde a los tres.

ZAP envía ataques reales. El escáner activo inyecta inyecciones SQL, XSS y más contra la aplicación objetivo. Esto tiene implicaciones serias:

• Solo puedes escanear activamente sistemas de tu propiedad o para los que tengas permiso explícito y por escrito.
• En BazarNube trabajamos siempre contra un entorno de staging propio, nunca contra producción ni contra la infraestructura de terceros (pasarelas de pago, CDNs, APIs externas).
• Un escaneo activo puede corromper datos, disparar correos, agotar recursos o tumbar el servicio. Trátalo como una prueba destructiva.
• Escanear un sistema ajeno sin autorización puede constituir un delito en la mayoría de jurisdicciones.

Esta advertencia se repetirá a lo largo del módulo. No es una formalidad: es la línea que separa el AppSec profesional del acceso no autorizado.

• Confundir "ZAP encuentra vulnerabilidades solo": ZAP solo prueba lo que ha visto pasar por su proxy. Si no exploras bien la app (manual + spiders), grandes zonas quedan sin analizar.
• Lanzar escaneo activo "para ver qué sale" sin scope: acabas atacando dominios de terceros. Define siempre el scope y trabaja en modo Protected.
• Creer que el escáner pasivo es suficiente: el pasivo no encuentra SQLi ni XSS; para eso necesitas el activo. Ambos son complementarios.
• Olvidar el AJAX Spider en SPAs: con un frontend React como el de BazarNube, el spider tradicional apenas ve nada. Necesitas el AJAX Spider.
• Consejo: empieza siempre por entender el tráfico como proxy antes de automatizar. Si no entiendes qué peticiones hace BazarNube, no interpretarás bien las alertas.

Ejercicio 1. Clasifica cada hallazgo según lo detectaría el escáner pasivo o el activo de ZAP: (a) la cookie de sesión de BazarNube no tiene el flag HttpOnly; (b) el buscador es vulnerable a SQLi; (c) falta la cabecera Content-Security-Policy; (d) un parámetro redirect permite redirección abierta.

Ejercicio 2. El equipo va a probar BazarNube en staging pero teme que ZAP toque por error la pasarela de pago externa pay.tercero.com, que aparece enlazada desde el checkout. ¿Qué modo de ZAP elegirías y qué debes configurar para evitarlo?

Ejercicio 3. Marc pregunta por qué el spider tradicional casi no encontró rutas del panel de vendedor de BazarNube, que es una SPA en React. Explica la causa y la solución dentro de ZAP.

Solución 1. (a) Pasivo: se detecta observando la cabecera Set-Cookie sin enviar nada nuevo. (b) Activo: requiere inyectar payloads y observar la respuesta. (c) Pasivo: es la ausencia de una cabecera en respuestas ya vistas. (d) Activo: hay que probar valores maliciosos en el parámetro redirect.

Solución 2. Elegir el modo Protected, que solo permite acciones intrusivas contra URLs dentro del scope. Definir el scope incluyendo únicamente el dominio de staging de BazarNube y excluyendo (o simplemente no incluyendo) pay.tercero.com. Así, aunque el spider descubra el enlace, ZAP no lanzará ataques contra él.

Solución 3. El spider tradicional solo sigue enlaces presentes en el HTML inicial. En una SPA React, las rutas y enlaces se generan dinámicamente con JavaScript tras la carga, así que apenas hay enlaces estáticos que seguir. La solución es usar el AJAX Spider, que maneja un navegador real capaz de ejecutar el JS y descubrir las rutas generadas.

Ya tienes el mapa mental de ZAP: un proxy de interceptación que además hace de escáner DAST, con piezas bien diferenciadas (sites tree, spiders, escáner pasivo y activo, alertas) y una serie de modos que acotan cuánto daño puede hacer. Has visto la distinción crítica entre pasivo (observar, seguro) y activo (atacar, solo en staging propio) y cómo ZAP cierra el bucle que abrimos con el Top Ten, ASVS y SAMM sobre BazarNube.

En la siguiente lección, 06-02 Instalación y Configuración, pasamos de la teoría a tener ZAP funcionando: lo instalaremos (paquete y Docker), configuraremos el navegador y el certificado raíz para inspeccionar HTTPS, y prepararemos el contexto, el scope y la autenticación necesarios para probar las zonas autenticadas de BazarNube.