Passive scanning reads traffic the app already produces and sends no attacks, so it is safe nearly anywhere. Active scanning sends crafted attack requests and finds deeper flaws, but belongs in a test environment. Most teams need both, at different points.
Definitions
- Passive scan: analysis of requests and responses that pass through the scanner, with no new attack traffic.
- Active scan: the scanner sends modified requests with attack payloads and judges the responses.
- Spider or crawler: the part that finds pages and endpoints to examine.
The ZAP documentation describes a passive scanner that scans messages, including HTTP and WebSocket, that are proxied through or sent by ZAP. Its baseline script runs the spider and waits for passive scanning to finish, and the docs state it performs no actual attacks. The full scan script adds an active scan, and the docs say that it does perform attacks and can potentially run for a long period.
What each finds
| Question | Passive | Active |
|---|---|---|
| Missing security headers | Yes | Not the focus |
| Cookies without protective flags | Yes | Not the focus |
| Information leaks in responses | Often | Sometimes |
| Injection flaws | Rarely | Yes |
| Cross-site scripting | Some reflected hints | Yes |
| Access control gaps | No | With more setup |
Passive scanning is limited to what it sees. If the app never returns a leak in a normal response, passive checks will not find it.
Where each belongs
| Setting | Recommended |
|---|---|
| Every pull request | Passive, short crawl |
| Nightly build on staging | Passive plus a light active policy |
| Weekly or release candidate on staging | Fuller active scan |
| Production | Passive only, unless you have explicit agreement and a plan |
| During manual QA | Passive, through a proxy |
An active scan can create records, send emails, lock accounts and load a server. Those are reasons to keep it away from production and from shared data.
Steps to adopt both
- Start with passive in the pipeline. It is cheap and has few side effects.
- Fix the easy items it finds, such as headers and cookie flags.
- Prepare a test environment for active scanning with fake data and a reset script.
- Add an active scan on a schedule, with a time limit and a named owner.
- Review both reports together. Passive findings are fast to fix. Active findings need triage.
- Revisit the mix each quarter based on what each one actually found.
Common confusions
- "Passive means it cannot hurt anything." Mostly true, but the crawl still sends requests, so keep it inside scope.
- "Active is always better." It finds more, but costs more time and carries more risk.
- "A passive-only report is a full test." It is not. It misses flaws that need crafted input.
A worked example
A team runs a small SaaS product with one staging environment. They decide what to run at each stage.
| Stage | Scan type | Duration | Who sees it |
|---|---|---|---|
| Pull request | Passive, one minute crawl | About 3 minutes | The author, in the check output |
| Merge to main | Passive, longer crawl, authenticated | About 10 minutes | The team channel |
| Nightly on staging | Passive plus light active policy | About 90 minutes | Security champion |
| Release candidate | Full active scan, multiple roles | Several hours | Security lead and service owner |
| Production | Passive checks on a schedule | Minutes | Operations |
The durations are illustrative. The principle is that cost and risk rise as you move from passive to active, so the cheap checks run often and the expensive ones run at gates.
What each stage catches
- Pull request, passive. Missing headers, weak cookie flags and accidental information leaks in responses. Developers fix them within the same change.
- Nightly, light active. Obvious injection and reflected input problems on common paths.
- Release candidate, full active. Deeper tests on login, payment and uploads, with more attack variations and more than one user role.
- Production, passive. Detects configuration drift, such as a header lost during a deployment.
Active scanning needs a safe place
Before you add active scans, prepare the environment. Seed fake data, route mail to a sink, use sandbox payments, snapshot the database and write a reset script. A team that skips this will learn why with their first overnight run, when thousands of junk records appear. For more, see the post on protecting test data from a scan.
A decision shortcut
Ask three questions about each environment.
- Can the data be rebuilt in minutes? If not, passive only.
- Does anyone depend on the environment during the scan? If yes, schedule off hours or use a copy.
- Do you own everything the scanner can reach? If not, tighten scope first.
Only when all three answers are comfortable should an active scan run.
What reports should say
State the mode in every report: "passive checks of the authenticated staging application as a standard user" or "active scan with this policy". Readers then understand what a clean result means. A passive-only clean report says that nothing obvious leaked. It does not say that injection flaws are absent.
Growing the program
Start with passive in the pipeline, fix what it finds, add the active scan on a schedule, and then add roles and flows. Measure the time between a finding and its fix. If that time grows, you have more noise than the team can handle, and the first step is to tune policy rather than add scans.
Where Safeguard fits
Passive and active scanning both test a running web app. For the open source libraries inside it, Safeguard offers SBOM and dependency scanning with reachability analysis, and a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Note which stages only observe the app and which stages send test input.
Quick check
Can I run an active scan against production?
Avoid it unless you have explicit agreement and a plan for side effects. Use passive checks there.
Does passive scanning find SQL injection?
Rarely. Injection needs crafted requests, which is what active scanning does.
Can passive scanning run safely in production?
Generally yes, since it adds no attack traffic, but the crawl still sends requests. Keep it inside scope, use a dedicated account and tell the operations team.
Sources
Last reviewed: 19 October 2026.
