OWASP ZAP baseline scan, passive and active scan explained
The OWASP ZAP official documentation describes three different levels of testing. A passive scan only reads traffic and changes nothing. A baseline scan is a ready-made script that crawls a site for a short time and reports passive findings, without attacking it. An active scan sends real attacks and belongs on systems you are allowed to test, ideally not production.
I am a freelance web developer in France and I sell audit and maintenance work, so I have an interest in this subject. ZAP itself is free, and a business with a developer on hand can run most of what follows without hiring me. This article sticks to what the ZAP project publishes, read on 1 November 2026, and adds the buyer's question: what does each scan actually allow you to conclude?
Passive scan: reading without touching
According to the ZAP passive scanner documentation, passive scanning does not change requests or responses in any way, which is why the project considers it safe. ZAP looks at the messages passing through it, in the background, while you or a crawler browse the application.
That gives you a clear scope. The ZAP getting started page says this method is good at spotting problems such as missing security headers or missing anti CSRF tokens. A security header is an instruction your server sends to the browser, for example to refuse being embedded in another site. A CSRF token protects a form against being submitted from somewhere else. The same page says passive scanning cannot find flaws such as cross-site scripting (XSS), which need malicious requests to reveal themselves.
What the baseline scan does in the official documentation
The baseline scan page describes a script shipped in the ZAP Docker images. It runs the ZAP spider (the crawler that follows links) against the target for one minute by default, waits for passive scanning to finish, then prints the results. The documentation states that it does not perform actual attacks and normally completes within a few minutes. The command it gives as an example is short:
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py -t https://www.example.com
Four details matter once you use it for real. All alerts are warnings by default, and a configuration file passed with -c can turn each rule into a failure or ignore it; -g generates that file. The -m option changes the spider duration, which is worth doing on a large site because one minute may not reach every page. The -j option adds a modern spider, useful when pages are built by JavaScript. Finally, the exit codes are what you plug into an automated pipeline: 0 for success, 1 for at least one failure, 2 for warnings without failure, and 3 for any other problem.
Active scan: a real attack, on purpose
The active scan documentation leaves no ambiguity: active scanning is an attack on the selected targets, and you should not use it on web applications you do not own. The full scan script packages this behaviour. It crawls with no time limit by default, then runs a full active scan, and its page warns that it performs real attacks and can run for a long time.
In practice, this means test data can end up in your database and forms can be submitted repeatedly. So point it at a staging copy, with your backups checked and any outgoing emails or payments disabled. Doing it on the live shop on a Saturday morning is how a security test becomes the incident.
| Mode | Sends attacks? | Good for | Where to run it |
|---|---|---|---|
| Passive scan | No | Missing headers, missing anti CSRF tokens | Any traffic you are allowed to inspect |
| Baseline scan | No | A quick recurring check in a deployment pipeline | Staging or production, after warning your host |
| Active or full scan | Yes | Injection and XSS type flaws that need malicious requests | A copy you own, with permission |
What no ZAP scan will tell you
This is the limit buyers most often miss. The active scan page states that logical vulnerabilities such as broken access control will not be found by any active or automated vulnerability scanning, and that manual penetration testing should supplement it. Broken access control means a logged-in customer changes a number in the address bar and sees someone else's order. For a shop, a client portal or a business application, that kind of flaw is often the one with the worst consequences, and a green report says nothing about it.
So a tool is one part of an audit. In France, the CNIL recommends scanning for vulnerabilities regularly and before each production release, and names OWASP ZAP among example tools, alongside protections against the OWASP Top 10. That supports the tool as a routine, not as a verdict. For the manual side, the OWASP Web Security Testing Guide is the methodology to look at.
When ZAP is not the right choice
If your site is a small brochure site with a contact form, a baseline scan and a review of its updates will usually be proportionate, and an expensive penetration test may not be. If you handle health data, payments or a customer area, stopping at a baseline scan would be too little, and a specialist penetration tester may suit you better than a general developer like me. And if nobody will read the results and fix them, running the tool only creates a document that lists known problems.
Before accepting an audit from anyone, including me, ask four things: which scans were run and against which environment, what was tested by hand, how false alarms were sorted, and who fixes the findings afterwards. A report that cannot answer those questions is a tool export with a logo on it.
A simple next step
A sensible first move is to run the baseline scan against your site and keep the report. If you would rather have someone do it and explain what matters, you can request a site audit or look at my hosting and maintenance service, where these checks fit into regular upkeep. You speak directly with the person who writes the code, and I reply within 24 working hours.