The ZAP scanner is a free, open-source dynamic application security testing (DAST) tool that finds vulnerabilities in running web applications by crawling them, watching their traffic, and firing attack payloads at the endpoints it discovers. If you need to test a live application from the outside — the way an attacker sees it — the ZAP vulnerability scanner is the most widely deployed option, and it costs nothing to start.
A bit of recent history matters for anyone searching for it today. The project originated as OWASP ZAP (Zed Attack Proxy). In 2023 it moved from OWASP to the Linux Foundation's Software Security Project, and in September 2024 the core maintainers joined Checkmarx, so the tool is now branded "ZAP by Checkmarx." It remains open source, community-controlled, and free to use — the rebrand did not change the license.
How the ZAP scanner actually works
ZAP sits between a client and the target application as an intercepting proxy, which is the key to everything it does. Because all traffic flows through it, ZAP can observe, modify, and replay requests. On top of that proxy foundation, four engines do the real work.
The spider crawls the application by following links and forms from a starting URL, building a map of reachable pages and parameters. It handles traditional server-rendered sites well but struggles with content that only appears after JavaScript runs.
The AJAX spider fills that gap. It drives a real headless browser to render JavaScript-heavy single-page applications, clicking and navigating the way a user would, so ZAP can discover endpoints that never appear in the raw HTML. For any modern React, Vue, or Angular front end, the AJAX spider is what makes coverage usable.
The passive scanner analyzes every request and response that flows through the proxy without sending anything extra. It flags missing security headers, cookies without the Secure or HttpOnly flags, information disclosure in responses, and similar issues. Because it adds no traffic, passive scanning is safe to run against any environment, including production.
The active scanner is the aggressive engine. It takes the endpoints and parameters discovered by the spiders and fires actual attack payloads — injection strings, path traversal sequences, and more — then inspects the responses for evidence the attack worked. This is where ZAP finds injection and similar server-side flaws, and it is also why you never point the active scanner at a system you do not own or lack permission to test.
Baseline scans versus full active scans
In practice most teams run ZAP in one of two modes, and choosing the right one is the difference between useful automation and a broken pipeline.
The baseline scan runs the spider and passive scanner only — no attacks. It completes in a couple of minutes, produces no risk of altering data, and is the right default for a CI pipeline on every pull request. It catches the large category of misconfigurations (headers, cookies, disclosure) that passive analysis is good at, fast enough not to slow anyone down.
The full scan adds the active scanner. It takes much longer — minutes to hours depending on the application's size — and because it sends real attack payloads it can create test data, trigger emails, or exercise destructive endpoints if you have not scoped it carefully. Reserve full scans for a dedicated test environment on a schedule (nightly or pre-release), not for every commit.
The mistake teams make is running a full active scan on every pull request against a shared environment, then wondering why the pipeline is slow and the database is full of junk records. Match the scan depth to the trigger.
Running ZAP in CI
ZAP ships official Docker images that make automation straightforward. A baseline scan against a running target is essentially one command:
docker run -t ghcr.io/zaproxy/zaproxy:stable \
zap-baseline.py -t https://your-test-app.example.com -r report.html
That produces an HTML report and exits with a non-zero status when it finds issues above your threshold, which is what lets it gate a pipeline. The -r flag writes the human-readable report; add -J for a JSON report your other tooling can parse.
Two configuration practices make ZAP in CI far more usable. First, maintain a context file that defines the scope (which URLs are in and out of bounds) and, critically, how to authenticate — most interesting functionality lives behind a login, and an unauthenticated scan only sees the front door. Second, maintain an alert filter / ignore file to suppress known false positives and accepted risks, so the pipeline fails only on genuinely new findings rather than the same noise every run. Without that tuning, teams learn to ignore ZAP's output, which defeats the point.
Where the ZAP scanner reaches its limits
ZAP is excellent at what DAST does, and it is honest to be clear about what DAST cannot do.
Because it tests a running application from the outside, ZAP finds vulnerabilities that are actually reachable and exploitable at runtime — a real strength, since it has near-zero false positives on things like reflected injection that it confirms by observing the response. But it has no view of your source code, so it cannot tell you where in the codebase a flaw lives, and it will miss logic flaws, vulnerabilities in code paths the spider never reached, and issues in dependencies that are not exercised during the scan.
That last gap is important. A DAST scanner does not know that your application ships a vulnerable version of a logging library or a serialization framework; it only sees behavior, not the bill of materials. Runtime testing and dependency analysis answer different questions, and mature programs run both. ZAP for the runtime surface, software composition analysis for the dependency surface, and static analysis for the code paths a black-box crawl never touches. Teams building out a full DAST practice typically pair a crawler like ZAP with SCA and SAST rather than treating any one of them as complete.
ZAP also depends heavily on crawl coverage. If the spider cannot reach an endpoint — because it is behind complex authentication, requires a specific multi-step workflow, or is only invoked by another service — ZAP cannot test it. Coverage is the ceiling on what any DAST tool can find, which is why the authenticated context configuration is worth the effort.
FAQ
Is the ZAP scanner still free after the Checkmarx acquisition?
Yes. ZAP moved to the Linux Foundation in 2023 and the core team joined Checkmarx in 2024, but the tool remains open source and free under its original license. It is now branded "ZAP by Checkmarx"; the code and community governance stayed open.
What is the difference between a ZAP baseline scan and a full scan?
A baseline scan runs only the spider and passive analysis — fast, non-intrusive, safe for CI on every commit. A full scan adds the active scanner, which sends real attack payloads, takes much longer, and should run only against a dedicated test environment you own.
Can ZAP scan single-page applications?
Yes, using the AJAX spider, which drives a headless browser to render JavaScript and discover endpoints that never appear in the static HTML. For React, Vue, or Angular apps, the AJAX spider is essential for meaningful coverage; the traditional spider alone will miss most of the application.
Does the ZAP vulnerability scanner replace dependency scanning?
No. ZAP tests a running application's behavior from the outside and has no view of your dependency tree. It will not detect a vulnerable library that is not exercised at runtime. Pair it with software composition analysis and static analysis for full coverage.