Guía práctica y honesta de ZAP, el escáner de seguridad antes conocido como OWASP ZAP. Del certificado raíz al pipeline de CI, con los avisos legales y los límites que nadie cuenta.
La primera vez que lancé un escaneo activo de ZAP contra un entorno equivocado aprendí algo que ninguna guía introductoria me había dejado claro: OWASP ZAP no "prueba" tu aplicación, la ataca de verdad. Envía inyecciones, fuerza parámetros, dispara formularios una y otra vez. Si apuntas a la máquina que no toca, dejas basura en la base de datos, disparas correos y, en el peor caso, tiras un servicio. Un escáner de seguridad es una herramienta ofensiva con interfaz amable, y esa amabilidad engaña.
Este artículo es la guía que me habría gustado leer entonces: qué es ZAP hoy, cómo se instala de verdad (incluido el paso del certificado que casi nadie cuenta), la diferencia entre mirar y atacar, cómo autenticarse sin volverse loco, cómo automatizarlo en un pipeline y, lo más importante, qué no va a encontrar por mucho que lo configures. Llevo más de veinte años escribiendo código y la conclusión no ha cambiado: un escáner encuentra lo que se puede encontrar sin entender el negocio. El resto sigue siendo tu trabajo.
ZAP son las siglas de Zed Attack Proxy. Es un escáner de seguridad de aplicaciones web de código abierto, gratuito y bajo licencia Apache 2.0, y una de las herramientas DAST (Dynamic Application Security Testing) más extendidas; el propio proyecto se presenta como "the world's most widely used web app scanner". DAST significa que prueba la aplicación en ejecución, desde fuera, como lo haría un atacante: no lee tu código fuente, interactúa con la aplicación viva.
Lo de la nomenclatura importa, y aquí es donde casi todos los tutoriales en español van desactualizados. El proyecto nació y creció dentro de OWASP, de ahí el nombre "OWASP ZAP" con el que lo conociste. En 2023 dejó OWASP y se integró en el Software Security Project. En septiembre de 2024, el núcleo del equipo se incorporó a Checkmarx, y hoy el proyecto se presenta oficialmente como "ZAP by Checkmarx". Su propia web lo deja claro en la cabecera y, a la vez, insiste en que sigue siendo "an independent Open Source project". O sea: cambió el patrocinador, no la licencia ni la naturaleza. Sigue siendo gratis, sigue siendo abierto, sigue estando en GitHub.
Digo esto porque si buscas documentación y te encuentras "OWASP ZAP" en un sitio y "ZAP by Checkmarx" en otro, no son dos herramientas: es la misma, contada en dos momentos distintos. A lo largo del texto la llamaré ZAP a secas, que es como se llama hoy.
Antes de tocar un botón hay que entender qué hace ZAP por dentro, porque si no, todo lo demás son pasos memorizados sin sentido.
ZAP es, en sus propias palabras, un "manipulator-in-the-middle proxy". Se coloca entre tu navegador y la aplicación web. Cada petición que sale del navegador pasa por ZAP antes de llegar al servidor, y cada respuesta del servidor pasa por ZAP antes de llegar al navegador. En ese punto intermedio, ZAP puede leer el tráfico, guardarlo, modificarlo al vuelo y reenviarlo.
Eso es lo que lo convierte en una herramienta de seguridad y no en un simple crawler. Un proxy de interceptación te deja ver la petición HTTP real, cabeceras, cookies, cuerpo, tokens, y editarla antes de que salga. ¿Quieres saber qué pasa si mandas precio=-1 en lugar de precio=100? Interceptas, cambias el valor a mano, sueltas la petición y observas la respuesta. Sin proxy no puedes hacer eso: el navegador solo te deja mandar lo que el formulario permite. El proxy rompe esa jaula.
El problema es que hoy casi todo va por HTTPS, y HTTPS está cifrado precisamente para que nadie en medio pueda leerlo. Un proxy de interceptación es, por definición, alguien en medio. Ahí entra el certificado raíz, y por eso es el paso que más gente se salta y luego no entiende por qué "no ve nada".
La instalación en sí no tiene truco. Vas a la web oficial, descargas el instalador para tu sistema (hay para Windows, Linux y macOS, y también una imagen Docker que muestro más abajo) y lo ejecutas. Necesita Java, pero los instaladores "con JRE" ya lo traen. La primera vez te pregunta si quieres persistir la sesión: para empezar, dile que no.
Lo que de verdad hay que hacer bien es lo siguiente. Para que ZAP pueda leer el tráfico HTTPS tiene que generar certificados sobre la marcha para cada dominio que visitas, firmados por una autoridad certificadora propia (la CA raíz de ZAP). Tu navegador no se fía de esa CA por defecto, y hace bien, así que hay que instalarla manualmente en el almacén de confianza. Sin este paso verás errores de certificado en cada página y el tráfico cifrado no se interceptará.
En ZAP: Tools → Options → Network → Server Certificates, y ahí exportas el certificado raíz (Save). Después lo importas donde corresponda:
Ajustes → Privacidad y seguridad → Certificados → Ver certificados → pestaña Autoridades → Importar, y marca la casilla de confiar para identificar sitios web.Y el segundo paso: apuntar el navegador al proxy de ZAP, que por defecto escucha en 127.0.0.1:8080. Aquí un consejo de quien ha perdido tiempo con esto: no toques el proxy de tu sistema ni el de tu navegador principal. Usa un perfil de navegador dedicado o, mucho mejor, el navegador que ZAP lanza ya preconfigurado con el botón Manual Explore / Launch Browser. Te ahorra el certificado y el proxy de un golpe, y no te deja el equipo enrutando todo tu tráfico personal a través de ZAP cuando cierras la sesión de pruebas.
Esta es la distinción que separa a quien sabe usar ZAP de quien solo le da a los botones. No son dos intensidades de lo mismo: son dos cosas distintas.
El escaneo pasivo observa. La documentación oficial es tajante: "Passive scanning does not change responses in any way and is considered safe". Mientras navegas por la aplicación con el proxy activo, ZAP analiza en segundo plano cada petición y respuesta que pasa y levanta alertas sobre lo que ve: cabeceras de seguridad ausentes, cookies sin el flag HttpOnly, contenido mixto, fugas de información en comentarios. No manda nada nuevo. No modifica nada. Es seguro ejecutarlo contra cualquier cosa, incluso producción, porque técnicamente no hace más que mirar el tráfico que tú ya estás generando.
El escaneo activo ataca. Coge los puntos de entrada que ha descubierto y les lanza ataques conocidos: inyecciones SQL, cargas XSS, manipulación de parámetros, path traversal. Genera tráfico nuevo y potencialmente destructivo para ver cómo responde la aplicación. Encuentra vulnerabilidades que el pasivo jamás vería, precisamente porque las provoca. Y por eso mismo no es seguro.
| Escaneo pasivo | Escaneo activo | |
|---|---|---|
| Qué hace | Observa el tráfico que ya generas | Envía ataques nuevos a la app |
| ¿Modifica peticiones? | No | Sí |
| ¿Es seguro? | Sí, oficialmente | No, es un ataque real |
| Encuentra | Cabeceras, cookies, fugas, config | Inyecciones, XSS, path traversal |
| ¿Contra producción? | Con cabeza, sí | Nunca sin autorización escrita |
La regla que uso: el pasivo lo dejo corriendo siempre, desde el minuto uno. El activo no lo lanzo hasta tener clarísimo contra qué apunto y con permiso para hacerlo.
Voy a poner esto en el tono que merece, porque es lo que la mayoría de guías en español no dice y es donde alguien puede meterse en un lío legal serio.
El escaneo activo de ZAP ATACA el objetivo. No es una metáfora. La propia herramienta lo advierte: "Active scanning is a real attack on those targets and can put the targets at risk, so do not use active scanning against targets you do not have permission to test". Un ataque real, que puede causar daño real.
De ahí, dos reglas que no se negocian:
Y una tercera, práctica: el escaneo activo se lanza contra un entorno de staging o pruebas, no contra producción. He visto un escaneo activo llenar una tabla de miles de registros basura, disparar cientos de correos de "bienvenida" y agotar las conexiones de la base de datos. Si el formulario de contacto manda emails, el escáner los mandará todos. Si hay un endpoint que cobra, tenlo en cuenta. Aísla el entorno antes de atacar.
Antes de escanear hay que descubrir qué hay que escanear. ZAP tiene que recorrer la aplicación y encontrar sus URLs, formularios y parámetros. Para eso están las arañas (spiders), y aquí hay un matiz reciente que casi ningún tutorial recoge.
Mi criterio: para una web clásica renderizada en servidor, el spider tradicional basta y va sobrado de rápido. Para una SPA o cualquier cosa con carga dinámica, Client Spider. El AJAX Spider solo si el Client Spider, por lo que sea, no me cubre un flujo concreto. Y sea cual sea, ninguna araña sustituye a explorar la aplicación tú mismo con el navegador y el proxy puesto: hay flujos (asistentes de varios pasos, acciones tras confirmación) que ningún crawler recorre solo.
Aquí es donde ZAP deja de ser fácil. La mayoría de aplicaciones que merece la pena escanear están detrás de un login, y si ZAP no sabe autenticarse, escanea la página de login mil veces y no ve nada de lo que importa.
El montaje mínimo tiene cuatro piezas que hay que configurar en orden:
Form-based Authentication. Le indicas la URL a la que se envía el POST y el cuerpo de la petición con marcadores: ZAP sustituye {%username%} y {%password%} por las credenciales reales. Queda algo como username={%username%}&password={%password%}. Para APIs con token, se usa autenticación por script o basada en JSON.Cookie-based Session Management.Logged in indicator y un Logged out indicator: un patrón (una regex) que aparece cuando estás dentro (por ejemplo Cerrar sesión) o cuando estás fuera (Iniciar sesión). Sin esto, ZAP no detecta cuándo pierde la sesión y sigue escaneando como anónimo sin enterarse.Y el error clásico, el que hace perder una tarde entera: excluir la URL de logout del ámbito. Si no lo haces, la araña o el escáner activo tarde o temprano piden /logout, la sesión se cae, y a partir de ahí todo el escaneo va sin autenticar. Añade la URL de cierre de sesión a las exclusiones del contexto y respira tranquilo.
Un contexto en ZAP es la definición de "esto es la aplicación que estoy probando". Ahí dentro vive la configuración de autenticación, los usuarios, la gestión de sesión y, crítico, el ámbito: qué URLs entran y qué URLs no.
El ámbito se define con dos listas de expresiones regulares: Include in Context y Exclude from Context. Esto no es burocracia, es seguridad operativa. Un Include bien puesto evita que ZAP se ponga a rastrear medio internet siguiendo un enlace externo. Un Exclude bien puesto evita tres desastres concretos: el logout que te tira la sesión, los endpoints destructivos (/borrar, /admin/reset) que no quieres que el escáner active toque, y cualquier subdominio o servicio de terceros que no te pertenece y que no tienes permiso para atacar.
Mi regla al montar un contexto: incluyo solo el dominio y las rutas que voy a probar, y antes de lanzar nada activo reviso la lista de exclusiones como si fuera una checklist de vuelo. Logout fuera. Acciones irreversibles fuera. Dominios ajenos fuera. Diez minutos ahí ahorran una limpieza de base de datos después.
La interfaz gráfica está muy bien para explorar y aprender, pero ZAP no vive de la GUI. Todo lo que hace se puede pilotar sin interfaz, y ahí es donde se convierte en una herramienta de verdad.
Modo demonio. Arrancas ZAP sin interfaz, escuchando en un puerto, listo para recibir órdenes:
./zap.sh -daemon -host 127.0.0.1 -port 8080 -config api.key=CLAVE_SECRETA
La api.key no es opcional en la práctica: sin ella, cualquier proceso de tu máquina puede mandarle órdenes a ZAP. Ponla siempre.
La API. Con el demonio levantado, ZAP expone una API REST. Puedes lanzar la araña, consultar el progreso o sacar las alertas con simples peticiones HTTP:
# Lanzar la araña sobre un objetivo
curl "http://127.0.0.1:8080/JSON/spider/action/scan/?apikey=CLAVE_SECRETA&url=https://staging.miapp.local"
# Sacar todas las alertas encontradas
curl "http://127.0.0.1:8080/JSON/core/view/alerts/?apikey=CLAVE_SECRETA&baseurl=https://staging.miapp.local"
El Automation Framework. Manejar la API a mano se hace pesado enseguida. La forma moderna de guionizar ZAP es un único fichero YAML que describe el plan completo, contexto, arañas, escaneo, informe, y se ejecuta de una vez. Un plan mínimo pero real:
env:
contexts:
- name: mi-app
urls:
- https://staging.miapp.local
includePaths:
- "https://staging.miapp.local.*"
excludePaths:
- "https://staging.miapp.local/logout.*"
parameters:
failOnError: true
progressToStdout: true
jobs:
- type: spider
parameters:
context: mi-app
url: https://staging.miapp.local
- type: passiveScan-wait
- type: activeScan
parameters:
context: mi-app
- type: report
parameters:
template: traditional-html
reportDir: /zap/wrk
reportFile: informe-zap
Y se lanza así:
./zap.sh -cmd -autorun plan.yaml
El orden de los jobs importa y refleja el flujo real: primero descubres con la araña, esperas a que el escaneo pasivo termine de procesar la cola (passiveScan-wait), luego lanzas el activo y por último generas el informe. Hay tipos de job para casi todo: spider, spiderAjax, activeScan, importación de definiciones OpenAPI/GraphQL, autenticación y tests que hacen fallar el plan si se incumple una condición.
Aquí es donde ZAP paga su instalación con creces: escaneo de seguridad automático en cada despliegue, sin que nadie tenga que acordarse. La vía más limpia es la imagen Docker oficial y los scripts empaquetados.
El escaneo baseline es el ideal para CI porque es rápido y no ataca: solo hace una araña limitada en el tiempo y reporta lo que encuentra el escáner pasivo. Perfecto para correr en cada pull request sin miedo:
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py -t https://staging.miapp.local
Fíjate en la imagen: ghcr.io/zaproxy/zaproxy:stable, la actual. Si ves tutoriales con owasp/zap2docker-stable, están anticuados; esa imagen quedó atrás con el cambio de gobernanza.
En GitHub Actions hay una acción oficial que envuelve todo esto y, además, abre issues automáticamente con los hallazgos:
on: [push]
jobs:
zap_scan:
runs-on: ubuntu-latest
name: Escaneo de seguridad
steps:
- name: ZAP Baseline Scan
uses: zaproxy/[email protected]
with:
token: ${{ secrets.GITHUB_TOKEN }}
docker_name: 'ghcr.io/zaproxy/zaproxy:stable'
target: 'https://staging.miapp.local'
Un consejo que me ahorra falsas alarmas en CI: el escaneo baseline, tal cual, marca como aviso hasta la cabecera de seguridad más menor, y eso pinta el pipeline de rojo por cosas que ya has decidido asumir. Se gestiona con un fichero de reglas (rules_file_name) donde silencias o degradas alertas concretas de forma explícita y versionada. Así el rojo del pipeline significa algo. El escaneo full (zap-full-scan.py), que sí incluye escaneo activo, lo reservo para entornos y ventanas controladas, nunca en cada commit. Si automatizar procesos repetitivos es tu terreno, este encaje entre seguridad y pipeline es un buen ejemplo de automatización con criterio: el valor no está en el script, está en decidir qué automatizar y qué no.
Terminas el escaneo, abres el panel de alertas y ves treinta hallazgos en rojo y naranja. La reacción instintiva, "esto es un desastre", casi siempre es errónea. Un escáner DAST genera falsos positivos, y saber descartarlos es la mitad del trabajo.
ZAP clasifica cada alerta por riesgo (High, Medium, Low, Informational) y por confianza (Confidence, de Low a High, incluida False Positive). Esa segunda columna es la que casi nadie mira y la que más importa. Un High con confianza Low no es una emergencia: es una pista que hay que verificar a mano.
Por qué hay tanto ruido: el escáner no entiende el contexto. Marca "posible SQL injection" porque un parámetro reflejó un carácter raro, cuando resulta que ese parámetro está tipado y validado tres capas más abajo. Marca XSS en un campo que en realidad se escapa correctamente en el render. Marca una cookie "insegura" que solo vive en el entorno local sin HTTPS. Ninguna de esas es real, pero el escáner no puede saberlo desde fuera.
El flujo que sigo con cada alerta: leer la evidencia concreta (ZAP te enseña la petición y la respuesta exactas que dispararon el aviso), reproducirla a mano para confirmar que el ataque de verdad funciona, y solo entonces decidir. Si es un falso positivo, lo marco como tal, o lo silencio en el fichero de reglas, para que no vuelva a ensuciar el siguiente informe. Una alerta que no verificas no es un hallazgo: es una hipótesis.
Y aquí está lo más honesto, que es también lo que ningún competidor cuenta porque no vende: un escáner no sustituye a una revisión. Encuentra lo que se puede encontrar sin entender el negocio. La lógica rota no la ve.
ZAP no sabe que un usuario del rol "comercial" no debería poder ver las facturas del rol "finanzas", porque técnicamente la petición funciona: devuelve un 200 con datos. Eso es un fallo de autorización de lógica de negocio, y para un escáner es una respuesta correcta. No sabe que tu descuento debería topar en el 50% y que mandar descuento=99 te sale gratis. No sabe que el flujo de recuperación de contraseña tiene un agujero conceptual. Todos esos son bugs de razonamiento sobre las reglas del negocio, y una máquina que no conoce esas reglas no puede detectarlos.
Lo he visto de cerca en mi propio código: un borrado automático que no borraba a quien debía por cómo SQL trata los valores nulos. Ningún escáner de seguridad del mundo habría levantado esa alerta, porque no había vulnerabilidad técnica: había una consulta que hacía exactamente lo que decía, y lo que decía estaba mal respecto a lo que el negocio necesitaba. Ese tipo de fallo lo encuentra una persona leyendo el código con el negocio en la cabeza, o una revisión adversarial pensada para romper el plan, no un crawler lanzando payloads.
Así que mi recomendación, después de toda esta guía, incluye un "cuándo no": no delegues tu seguridad en ZAP y te quedes tranquilo. Úsalo para lo que es bueno, cubrir de forma automática y barata la capa de vulnerabilidades técnicas conocidas, en cada despliegue, y reserva el juicio humano para lo que una máquina no alcanza. Si necesitas esa segunda capa, la de alguien que lea el negocio y no solo el tráfico, hablamos de tu proyecto y te digo con franqueza qué cubre una herramienta y qué no.
Todo lo técnico de este artículo está contrastado con la documentación oficial, y es donde te mando a profundizar. La guía de inicio de ZAP (zaproxy.org/getting-started) explica arañas y escaneos con las advertencias en su fuente original; el Automation Framework tiene la referencia completa de tipos de job para el YAML; y el material de OWASP sigue siendo la mejor base para entender las categorías de vulnerabilidades que ZAP busca. Empieza por ahí, monta el proxy, deja el escaneo pasivo corriendo y no lances nada activo hasta tener el permiso por escrito. Ese es el orden que funciona.
ZAP (Zed Attack Proxy), conocido durante años como OWASP ZAP, es un escáner de seguridad de aplicaciones web gratuito y de código abierto. Funciona como proxy de interceptación entre tu navegador y la aplicación, y sirve para detectar vulnerabilidades técnicas como inyecciones SQL, XSS o cabeceras de seguridad ausentes, tanto de forma manual como automatizada. Es la herramienta DAST (pruebas dinámicas) más usada del mundo.
El proyecto dejó OWASP en 2023 y pasó por el Software Security Project. En septiembre de 2024 el núcleo del equipo se incorporó a Checkmarx, y hoy se presenta oficialmente como ZAP by Checkmarx. Pese al cambio de patrocinador, sigue siendo un proyecto independiente, de código abierto y bajo licencia Apache 2.0. Es la misma herramienta que conocías como OWASP ZAP, con otro nombre.
El escaneo pasivo, que solo observa el tráfico, es seguro. El escaneo activo es distinto: la propia herramienta advierte de que es un ataque real contra el objetivo. Solo debes lanzarlo contra sistemas propios o de un cliente que te lo haya encargado, y siempre con autorización por escrito que defina el alcance. Escanear activamente un sistema ajeno sin permiso constituye acceso no autorizado y es delito en muchas jurisdicciones, España incluida.
El escaneo pasivo observa el tráfico que ya generas navegando, no modifica nada y es seguro incluso contra producción: detecta cabeceras, cookies y fugas de información. El escaneo activo envía ataques nuevos a la aplicación (inyecciones, XSS, path traversal) para provocar y detectar vulnerabilidades; encuentra más, pero es un ataque real que puede dañar el sistema, así que solo se lanza contra entornos de prueba y con permiso.
La vía más limpia es la imagen Docker oficial ghcr.io/zaproxy/zaproxy:stable con los scripts empaquetados. Para CI se usa el escaneo baseline (zap-baseline.py), que es rápido y no ataca, ideal para cada pull request. En GitHub Actions existe la acción oficial zaproxy/action-baseline, que corre el escaneo y abre issues con los hallazgos. Un fichero de reglas te permite silenciar falsos positivos para que el pipeline solo falle por lo que importa.
No. ZAP encuentra vulnerabilidades técnicas que se pueden detectar sin entender el negocio, pero no ve los fallos de lógica de negocio: que un rol acceda a datos que no le tocan, que un descuento no tenga tope o que un flujo tenga un agujero conceptual son cosas que un escáner interpreta como respuestas correctas. Además, buena parte de sus alertas son falsos positivos que hay que verificar a mano. Un escáner complementa, no sustituye, a una revisión humana.
Si tienes un problema parecido y quieres una opinión técnica, cuéntamelo. Te respondo en menos de 24 h laborables.