system onlinepath: /guias/hacking/owasp-zap-desde-cero/mode: knowledge_baselocal:
Hacking ético · Nivel intermedio

OWASP ZAP desde cero para analizar aplicaciones web

El proxy de intercepción libre: la diferencia entre escaneo pasivo, exploración y escaneo activo, cómo se define el alcance con contextos, y qué encuentra y qué nunca va a encontrar solo un escáner automático.

14 min de lectura▣ Publicada el ◇ Por Underc0de
Respuesta rápida

ZAP (Zed Attack Proxy) es un proxy de intercepción libre y de código abierto para auditar aplicaciones web. El concepto de fondo —interceptar, inspeccionar y modificar tráfico— ya lo viste en la guía de Burp Suite; lo propio de ZAP son tres modos que se combinan dentro de un alcance definido: la exploración descubre URLs siguiendo enlaces, el escaneo pasivo analiza el tráfico que ya pasó sin generar peticiones nuevas, y el escaneo activo ataca de verdad con técnicas conocidas y exige autorización explícita. Ningún escáner automático, tampoco este, reemplaza el análisis manual: hay fallas que solo encuentra una persona que entiende el negocio.

Ver índice de contenidos
  1. 01Qué es ZAP y qué lo distingue de Burp
  2. 02Antes de nada: el contexto define el alcance
  3. 03Los tres modos, uno por uno
  4. 04Qué encuentra y qué nunca va a encontrar solo
  5. 05Primer análisis paso a paso
  6. 06Integración en pipelines: Automation Framework
  7. 07Errores frecuentes
  8. 08Preguntas frecuentes
  9. 09Fuentes

Qué es ZAP y qué lo distingue de Burp

En la guía de Burp Suite ya viste qué es un proxy de intercepción y por qué cambia todo: la petición se edita después de que el navegador la armó. ZAP (Zed Attack Proxy) resuelve el mismo problema, con una diferencia de fondo: es libre y de código abierto, sin funciones bloqueadas detrás de una licencia paga. El propio sitio se define así: «the world's most widely used web app scanner. Free and open source. A community based GitHub Top 1000 project that anyone can contribute to».

i
Una aclaración necesaria sobre a quién pertenece hoy

Durante años se lo conoció como «OWASP ZAP», porque nació como proyecto de esa fundación —lo mismo que vas a leer en foros y cursos más viejos—. La gobernanza institucional cambió de manos más de una vez desde entonces. Al momento de escribir esta guía (29 de julio de 2026), el sitio oficial se presenta bajo la marca «ZAP by Checkmarx» —así figura en el logo y en el pie de cada página— y su FAQ no menciona una afiliación activa con OWASP. Si necesitás citar a qué organización pertenece hoy, no lo des por sentado: revisá el sitio oficial en el momento.

La consecuencia práctica de ser libre está en lo que trae adentro. En Burp Community, el escáner automático y el guardado de proyectos quedan del lado de la edición paga. En ZAP, exploración, escaneo pasivo, escaneo activo y automatización conviven en la misma instalación gratuita. La condición real es entender cuándo corresponde cada uno, porque el activo —ya lo vas a ver— es un ataque de verdad.

Antes de nada: el contexto define el alcance

Un contexto en ZAP agrupa un conjunto de URLs bajo un mismo alcance. La documentación oficial lo define como algo que debería corresponder a una aplicación web, armado con expresiones regulares (regex) que se comparan contra la URL completa de cada entrada del árbol de sitios. La recomendación oficial es crear un contexto por cada aplicación del sistema evaluado, y ponerlo «en alcance» a medida que se prueba.

Definir el contexto antes de navegar cumple la misma función que el alcance en Target de Burp: todo lo que el proxy capture fuera de esas URLs queda afuera de lo que vas a explorar y escanear. Un navegador moderno habla con muchos más dominios que el que te interesa —analítica, tipografías, actualizaciones—, y sin un contexto bien definido todo eso entra también en el mapa de sitios. El marco legal completo —autorización escrita, alcance documentado, laboratorio aislado— está en fundamentos de hacking ético, y acá se aplica sin excepciones.

Los tres modos, uno por uno

Los tres modos de ZAP no son intercambiables, y confundirlos tiene consecuencias reales: uno descubre, otro observa y el tercero ataca.

Exploración (spider)

La exploración —el spider, palabra que en inglés significa araña y así se llama la función en el menú— descubre URLs nuevas. Arranca con una lista semilla de direcciones, visita cada recurso, identifica los enlaces del HTML —incluidos los que aparecen en atributos menos obvios, como el src de un script o el href de un elemento SVG— y agrega lo encontrado a la cola por visitar, de forma recursiva, mientras aparezcan recursos nuevos.

También puede analizar robots.txt y sitemap.xml como fuentes adicionales, si lo configurás así. Acá hay un detalle que no conviene dar por sentado: la documentación oficial dice explícitamente que el spider no respeta las reglas de robots.txt; solo puede usarlo, si está activado, como una fuente más de URLs, nunca como una restricción. El límite real de la exploración lo pone el contexto, no ese archivo.

Escaneo pasivo

El escaneo pasivo no manda nada nuevo: analiza el tráfico que ya pasó por el proxy, generado a mano o por la exploración. Corre automáticamente en paralelo, sin que lo actives vos, y por eso no es intrusivo: se puede dejar siempre encendido sin arriesgar nada del servidor. Revisa respuestas y encabezados en busca de indicios —una cookie sin el atributo correcto, un encabezado de seguridad ausente, información que se filtra en un mensaje de error— y los convierte en alertas. Cuantas más páginas visites, más material tiene para revisar.

Escaneo activo

El escaneo activo es otra cosa, y la documentación oficial es tajante en dos puntos que conviene citar tal cual. El primero: «active scanning attempts to find potential vulnerabilities by using known attacks against the selected targets» —intenta encontrar vulnerabilidades usando ataques conocidos contra los objetivos seleccionados—. El segundo, más directo todavía: «active scanning is an attack on those targets», con la advertencia de que no debería usarse en aplicaciones web que no sean propias. No es una figura retórica: manda peticiones diseñadas para disparar comportamientos vulnerables, indistinguibles de un ataque real.

El tercer punto es el que hace honesta esta guía: la misma documentación aclara que el escaneo activo solo puede encontrar ciertos tipos de vulnerabilidad, y que las vulnerabilidades lógicas —como un control de acceso roto— no las va a encontrar ningún escaneo activo ni automático. Por eso el propio proyecto recomienda sumar siempre pruebas de penetración manuales, para cubrir lo que la automatización no ve.

Diagrama de tres pasos dentro de un contexto que acota el alcance con expresiones regulares sobre URLs. Primero la exploración (spider), que descubre URLs siguiendo enlaces y no respeta las reglas de robots.txt por defecto. En paralelo, el escaneo pasivo, que solo analiza el tráfico que ya pasó por el proxy sin generar peticiones nuevas. Por último, el escaneo activo, que ataca el objetivo con técnicas conocidas, requiere autorización expresa y solo detecta ciertos tipos de vulnerabilidad. Una franja inferior aclara que las fallas de lógica de negocio y el control de acceso roto no los encuentra ningún escáner automático: hace falta análisis manual.
Exploración y escaneo pasivo pueden convivir mientras navegás; el escaneo activo es un paso aparte, deliberado, y por eso exige autorización.
Diferencias entre los tres modos de ZAP
Modo¿Genera peticiones nuevas?¿Es intrusivo?¿Necesita autorización explícita?
Exploración (spider)Sí, para descubrir enlacesEn general, noSí, el mismo criterio que el resto del trabajo
Escaneo pasivoNo, solo observaNoNo adicional: corre sobre tráfico ya autorizado
Escaneo activoSí, con payloads de ataqueSí, es un ataqueSí, imprescindible y por escrito

Qué encuentra y qué nunca va a encontrar solo

Tanto el escaneo pasivo como el activo devuelven alertas, y cada una corresponde a un patrón que el proyecto ya conoce: una cabecera de seguridad ausente, una firma de inyección, un parámetro reflejado sin codificar. Eso cubre buena parte de las categorías más comunes del OWASP Top 10 2025, sobre todo las que dependen de un patrón sintáctico reconocible. Como cualquier escáner automático, además, puede producir falsos positivos: alertas que señalan un problema que en los hechos no existe, porque una respuesta genérica coincidió por casualidad con el patrón buscado. Ninguna alerta se reporta sola: se confirma a mano antes de darla por buena.

Lo que ningún escáner puede ver es lo que depende del negocio, no de la sintaxis. La categoría que más se le escapa es la primera del Top 10: el control de acceso roto. Que la cuenta 1042 pueda ver los datos de la cuenta 1043 no rompe ninguna regla del protocolo HTTP: hace falta saber qué identificador le pertenece a quién, y eso es conocimiento humano del sistema. Lo mismo pasa con la lógica de negocio: un carrito que acepta una cantidad negativa, un descuento aplicable dos veces, un flujo que se salta cambiando el orden de las peticiones. Nada de eso es un «ataque conocido»: es una decisión de diseño que salió mal.

Por eso la conclusión no es una frase de cortesía: un escáner automático no reemplaza el análisis manual, ni en ZAP ni en ningún otro. Sirve para cubrir terreno rápido y consistente y dejar tiempo libre para lo que sí requiere criterio humano.

  • Autorización escrita y alcance definido, igual que en cualquier auditoría —ver fundamentos de hacking ético.
  • Contexto configurado con las URLs exactas que corresponden.
  • Entorno propio o de laboratorio, nunca producción de un tercero sin ese papel firmado.
  • Aviso a quien opera el sistema, si no es un laboratorio aislado.
  • Política de escaneo revisada, no la que viene por defecto sin mirarla.

Primer análisis paso a paso

  1. Descargar ZAP desde el sitio oficialInstalador para Windows, Linux o macOS, o imagen de Docker, siempre desde zaproxy.org. Los instaladores no están firmados: es normal que el sistema muestre una advertencia al abrirlos, no una señal de que el archivo esté alterado.
  2. Definir el contexto con el alcance realAntes de navegar, creá un contexto con las expresiones regulares que cubren únicamente las URLs de tu laboratorio o tu propia aplicación.
  3. Explorar la aplicaciónNavegá con el proxy activo, o dejá que la exploración descubra URLs a partir de la semilla que definas.
  4. Revisar las alertas del escaneo pasivoCorre solo, sobre todo lo que ya pasó por el proxy. Revisalas antes de seguir: no cuestan nada y ya te dicen bastante.
  5. Lanzar el escaneo activo recién con la autorización confirmadaEs el único paso que ataca de verdad. Hacelo solo sobre tu propia aplicación o con autorización escrita.
  6. Exportar el informe y verificar cada alerta a manoCruzá cada hallazgo, pasivo y activo, con una comprobación manual: un escáner automático puede equivocarse.

Para practicar estos pasos sin exponer nada real, el objetivo natural es una aplicación deliberadamente vulnerable en tu propio laboratorio: la comunidad de Underc0de ya combinó ZAP con DVWA para un ataque de fuerza bruta contra un formulario de acceso, en el hilo citado más abajo.

Integración en pipelines: Automation Framework

ZAP incluye un complemento propio pensado para integración continua (CI/CD, siglas de continuous integration / continuous delivery): el Automation Framework. Todo se define en un archivo de plan, y los jobs que lo componen —exploración, espera del escaneo pasivo, escaneo activo, entre otros— se ejecutan en el orden en que aparecen, de arriba hacia abajo, desde la línea de comandos:

Bash
# Ejecutar un plan de automatización sin abrir la interfaz gráfica
zap.sh -cmd -autorun plan.yaml

# Generar una plantilla de plan con los parámetros clave
zap.sh -cmd -autogenmin plantilla.yaml

# Verificar que un plan es válido antes de correrlo en el pipeline
zap.sh -cmd -autocheck plan.yaml

El resultado también está pensado para un pipeline: al terminar, ZAP devuelve un código de salida que un paso de integración continua puede leer sin abrir ningún informe. Por defecto es 0 si el plan se completó sin errores ni advertencias, 1 si reportó algún error, y 2 si solo reportó advertencias. Un plan típico encadena la exploración (job spider), una espera a que termine el escaneo pasivo (job passiveScan-wait) y recién al final, si el plan lo indica, el escaneo activo (job activeScan): primero se descubre y se deja correr el análisis silencioso, y solo después se dispara lo que ataca de verdad.

Errores frecuentes

  • Confundir escaneo pasivo con escaneo activo. El pasivo es automático y silencioso; el activo hay que dispararlo a propósito.
  • Suponer que robots.txt limita al spider. No lo hace: solo puede usarlo como una fuente más de URLs, no como restricción.
  • Creer que un escaneo, pasivo o activo, encuentra todo. Ninguno ve fallas de lógica de negocio ni control de acceso roto: eso se prueba a mano.
  • Escanear un objetivo sin autorización. El escaneo activo es un ataque real, con las mismas consecuencias legales que cualquier acceso no autorizado.
  • No definir el contexto. Sin acotarlo, el spider y los escaneos trabajan sobre todo lo que el proxy capturó, incluidos dominios de terceros.
  • Usar la política de escaneo por defecto sin revisarla. Genera más tráfico del necesario y puede degradar un servicio.

Preguntas frecuentes

¿Qué diferencia hay entre exploración, escaneo pasivo y escaneo activo?

La exploración (spider) descubre URLs nuevas siguiendo enlaces desde una lista semilla, de forma recursiva, y puede apoyarse en robots.txt y sitemap.xml como fuentes adicionales. El escaneo pasivo analiza el tráfico que ya pasó por el proxy sin generar ninguna petición nueva: corre automáticamente y no es intrusivo. El escaneo activo manda peticiones diseñadas para disparar comportamientos vulnerables usando ataques conocidos, y la documentación de ZAP lo describe como un ataque real contra el objetivo. Los tres se combinan dentro de un contexto que define qué URLs entran en el alcance.

¿Por qué el escaneo activo es un ataque y necesita autorización?

Porque no se limita a observar: envía payloads pensados para explotar vulnerabilidades conocidas. La documentación oficial de ZAP lo dice sin matices: es un ataque contra los objetivos seleccionados y no debería usarse en aplicaciones que no sean propias. Practicarlo sin autorización sobre un sistema ajeno es intentar acceder a un sistema sin consentimiento, con las mismas consecuencias legales que cualquier otro ataque. Los contextos legítimos son tres: tu propia aplicación, un trabajo con autorización escrita y alcance definido, o un laboratorio armado para practicar, como el que se arma con DVWA.

¿Qué encuentra y qué no encuentra ZAP solo?

Encuentra bien lo que responde a un patrón reconocible: cabeceras de seguridad ausentes, firmas de inyección, parámetros reflejados sin codificar. No encuentra lo que depende del negocio y no de la sintaxis: fallas de lógica, como un carrito que acepta una cantidad negativa, y sobre todo el control de acceso roto, que exige saber qué recurso le pertenece a quién. La propia documentación recomienda sumar siempre pruebas de penetración manuales, precisamente porque las vulnerabilidades lógicas no las encuentra ningún escaneo automático.

¿Cómo configuro el proxy y por qué el contexto acota el alcance?

La configuración del proxy en sí —apuntar el navegador a ZAP e instalar su certificado— sigue la misma lógica de la guía de Burp Suite. Lo propio de ZAP es el contexto: expresiones regulares que se comparan contra la URL completa de cada entrada del árbol de sitios. La documentación recomienda un contexto por cada aplicación del sistema evaluado, activado en alcance a medida que se prueba. Sin un contexto bien definido, el spider y los escaneos trabajan sobre todo lo que el proxy capturó, incluidos dominios que nadie autorizó.

¿ZAP es gratis del todo, a diferencia de Burp?

Sí. ZAP se presenta oficialmente como libre y de código abierto, sin funciones bloqueadas detrás de una licencia paga: exploración, escaneo pasivo, escaneo activo y automatización conviven en la misma instalación gratuita. Eso contrasta con Burp Suite, donde la edición Community —también gratuita— deja el escáner automático y el guardado de proyectos del lado de la edición Professional, que es paga. La elección entre ambas suele ser de contexto: Burp es el estándar que piden muchos empleos, ZAP no tiene límites de funciones y se integra mejor en canalizaciones de integración continua.

¿Sigue siendo un proyecto de OWASP?

No es tan simple como sí o no. ZAP nació dentro de OWASP —de ahí «OWASP ZAP», nombre que todavía circula en cursos y material antiguo—, pero su gobernanza cambió de manos más de una vez. Al momento de escribir esta guía, el sitio oficial se presenta bajo la marca «ZAP by Checkmarx», así figura en su logo y en el pie de cada página, y su FAQ no menciona una afiliación activa con OWASP. Es un dato que envejece rápido: antes de citarlo en un informe formal conviene revisar el sitio oficial en el momento, en lugar de dar por buena una afiliación que puede haber cambiado.

Fuentes

Documentación oficial y aportes de la comunidad consultados para esta guía. Fecha de consulta: 29 de julio de 2026.

Aportes de la comunidad Underc0de

  1. Underc0de, foro. Zaproxy - Proxy de ataques de Owasp, por ANTRAX, 28 de octubre de 2019, sección Herramientas Hacking. Origen del interés de la comunidad por la herramienta.
  2. Underc0de, foro. Uso de ZAP - SQLI y XSS, por xyz, 19 de marzo de 2017, sección Seguridad web y en servidores. Primer caso de uso práctico en el foro; la interfaz cambió mucho desde entonces.
  3. Underc0de, foro. [SOLUCIONADO] Bruteforce a la página de login de DVWA con OWASP ZAP, por jmgarciag, con respuestas de DtxdF, 26 de octubre de 2018. La comunidad ya combinó ZAP con DVWA en un laboratorio propio.

Documentación oficial

  1. ZAP. Getting Started. ZAP como proxy manipulador en el medio y el Quick Start add-on.
  2. ZAP. Passive Scan. Descripción oficial del escaneo pasivo.
  3. ZAP. Active Scan. Las dos advertencias centrales: es un ataque y solo encuentra ciertos tipos de vulnerabilidad.
  4. ZAP. Spider add-on. Funcionamiento de la exploración y la aclaración sobre robots.txt.
  5. ZAP. Contexts. Cómo se arma un contexto para acotar el alcance.
  6. ZAP. Automation Framework. Línea de comandos, orden de los jobs y códigos de salida.
  7. ZAP. FAQ. Sin menciones activas a OWASP en su afiliación institucional.
  8. ZAP. Sitio oficial. Fuente de la marca «ZAP by Checkmarx» y de su descripción como libre y de código abierto.
  9. ZAP. Download. Formatos de instalación y advertencia sobre instaladores sin firmar.