OWASP ZAP en Docker: escanear tu aplicación Laravel en local
Hola, bienvenido. En esta lección vamos a escanear invoices con OWASP ZAP, en Docker y en local. ZAP es un escáner de aplicaciones web de código abierto que mira la aplicación desde fuera, a través de sus respuestas HTTP: las cabeceras, las cookies, lo que enseña una página de error. Vamos a lanzar su baseline scan desde un script, a leer el informe, a separar lo que es un problema de lo que no, y a fijar en un archivo de reglas qué hace fallar el escaneo.
¿Qué aporta ZAP si ya tenemos tests y una auditoría? Que los 2 miran el código, y hay cosas que solo se ven en la respuesta. Una cabecera que añade el servidor, una cookie que pone el framework o lo que devuelve una redirección no están en ningún archivo que hayas escrito, y ZAP las ve igual que las vería cualquier escáner de los de la lección 11.
Antes de empezar, una regla del curso: ZAP se lanza solo contra invoices, en tu máquina. El script de esta lección apunta a http://laravel.test, un nombre que solo existe dentro de la red de Sail, y no admite otro destino. Nunca lo lances contra una aplicación que no sea tuya.
Qué hace el baseline scan
ZAP trae varios escaneos ya preparados en sus imágenes de Docker, y el baseline scan es el más ligero. Según su documentación, lanza el spider de ZAP contra la aplicación durante 1 minuto por defecto. El spider recorre las páginas siguiendo los enlaces y los formularios que encuentra. Después, ZAP espera a que termine el escaneo pasivo y da el resultado. El escaneo pasivo solo analiza las peticiones y las respuestas que ha visto el spider, así que, como dice la documentación, no hace ningún ataque y termina en unos pocos minutos como mucho.
Cada comprobación de ZAP es una regla con su número, y el resultado de cada regla sale con uno de estos niveles:
| Nivel | Qué significa |
|---|---|
| PASS | La regla se ha aplicado y no ha encontrado nada |
| WARN | La regla ha encontrado algo. Es el nivel por defecto de todo lo que encuentra |
| FAIL | La regla ha encontrado algo y está marcada para hacer fallar el escaneo |
| INFO e IGNORE | La regla ha encontrado algo y el archivo de reglas lo baja a informativo o lo ignora |
FAIL, INFO e IGNORE dependen de un archivo de reglas que vamos a escribir más adelante en esta lección. Y el resultado también se ve en el código de salida del escaneo: 0 si todo ha ido bien, 1 si hay al menos un FAIL, 2 si hay algún WARN y ningún FAIL, y 3 si ha fallado otra cosa.
Ten en cuenta desde ya que el escaneo entra en invoices sin sesión. Solo ve lo que ve cualquier visitante, que es la página de login y las redirecciones que llevan a ella. Es poco, pero es justo lo que ve un escáner masivo, que tampoco tiene tus credenciales.
Para seguir la lección necesitas invoices levantado con Sail y Docker con sitio para la imagen de ZAP. Usamos la etiqueta stable, que en septiembre de 2026 trae ZAP 2.17 y ocupa varios GB en disco. Según la documentación de ZAP, esa imagen se actualiza con cada versión completa y se regenera cada mes con los últimos complementos. La descargamos antes de nada:
- 02El script zap/scan.sh
- 03Cómo se lee el informe
- 04Las reglas: qué hace fallar el escaneo
- 05Los informes, fuera de git
- 06Lo que el baseline scan no ve