Passive or active API scan: what does each mode actually find?

A passive API scan reads traffic and responses without attacking, so it is safe almost anywhere but finds mostly configuration and exposure issues. An active scan sends crafted requests and can find injection and authorization flaws, so it belongs in a test environment you can reset.

Definitions

Passive (baseline) mode observes the requests and responses it sees or makes in normal use, and flags what is visible: missing headers, cookie flags, leaked details in responses, version banners.

Active mode sends requests designed to provoke a weakness: altered parameters, injected values, different accounts' IDs, unusual methods.

The open-source ZAP API scan script shows how a tool exposes this choice. It imports an API definition in OpenAPI, SOAP or GraphQL form and runs an active scan against the URLs it finds. A safe mode flag skips the active scan and performs a baseline scan, which means passive checks only. Rules set to IGNORE in its config are not run during active scanning.

What each mode tends to find

The pattern: passive sees what a response contains, active tests what the server allows.

Where to run which

1. Production. Passive only, or a handful of agreed manual checks. Cloud providers publish testing policies that prohibit flooding and excessive-traffic fuzzing, so active automated testing against shared infrastructure needs care.
2. Shared staging with realistic data. Passive always. Active with an allow list of methods and paths.
3. A disposable environment seeded with synthetic data. Full active, with write methods, using test accounts.
4. CI on every pull request. A short passive or targeted active run, depending on the time budget.

Make passive results count

A clean passive scan is not a clean bill of health. Treat it as a low-cost routine: it catches regressions in headers and error handling and keeps an eye on changes. Report it as "passive scan completed" rather than "API tested", so nobody reads more into it than it says.

Make active results reliable

Active scans give meaningful results only if the scanner is authenticated and has more than one account. A scan that is logged out gets 401 for everything and reports little. Check the logs at the start of each run to confirm the session is live.

Tuning

Active rules vary in how disruptive they are. Start with a config that sets each rule to ignore, warn or fail, as the ZAP script allows, and turn up what you can safely run. Record which rules are off and why, so a gap in coverage is a decision and not an accident.

Worked example: one API, three scans

Take an invoicing API with a staging environment seeded with synthetic data. The team runs three scans in sequence and records what each finds.

Scan 1: passive baseline, no login. The scan sends the spec's GET requests without credentials and reads the responses. Results: most routes return 401, as expected. One public route returns a server version header. Cookie flags are missing on a session cookie set by the login route. A verbose error includes a file path. Three low-severity findings, all about information and configuration. Nothing about authorization, because no authenticated requests were made.

Scan 2: passive baseline, logged in as one user. Now the scan sees real responses. It flags that a list response includes a field that looks like an internal note, and that one response lacks a cache-control header on personal data. Two more findings. It still sends no attack requests, so object and function level checks remain untested.

Scan 3: active, two users and an admin, seeded staging. Now the scan sends altered requests. It finds that user B can read user A's invoice by ID, that a normal user can call an admin refund route, and that a search parameter returns a database error on a quote character. Three higher-severity findings, none of which scans 1 and 2 could have produced.

What each is good for. Scan 1 is cheap enough to run on every pull request or even against production. Scan 2 adds more signal for little risk. Scan 3 is the one that finds serious flaws, and it needs a safe place to run.

Mapping modes to the pipeline

A practical arrangement for this team:

1. On pull request: scan 1 or 2 against an ephemeral environment, with a short time budget. Fail only on a small set of rules the team agrees on.
2. Nightly: scan 3 against staging, after a reseed. Review new findings each morning.
3. Before a major release: scan 3 plus a manual pass for business logic and usage limits.
4. Production: scan 1 against public routes on a schedule, with a person reviewing any findings.

Configuration notes

Record which rules are off in the active scan and why. The ZAP API scan, for instance, lets you set each rule to ignore, warn or fail in a config file, and rules set to ignore are skipped in active scans. A rule disabled during a bad week and never restored is an easy way to lose coverage without noticing.

Reporting honestly

Label each report with its mode. "Baseline scan, one user, no write methods" tells a reader what the result means. "Security scan passed" does not.

Try it yourself

Open the demo and decide which of the example findings a passive scan could have produced, and which needed requests sent as another user.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• ZAP API scan documentation
• AWS penetration testing policy
• Microsoft Cloud penetration testing rules of engagement
• OWASP WSTG: API broken object level authorization

Last reviewed: 19 October 2026.