Before the first run, an API scanner needs five things: a description of the API (usually an OpenAPI file), a safe target environment, test accounts for each role, seeded data that belongs to different users, and a clear scope. Without them the scan tests very little or does harm.
The preparation list
| Input | Why it matters |
|---|---|
| API definition (OpenAPI, SOAP or GraphQL schema) | Tells the scanner which operations exist |
| Target URL | Staging or a test copy, not production by default |
| Test users, one per role | Needed for authenticated and function level tests |
| Records owned by different users | Needed to test object level authorization |
| Scope and exclusions | Keeps the scan away from payment, email and other live side effects |
Choosing the target
Active scanning sends attack style requests, creates and deletes data, and can trigger real side effects. ZAP's API scan documentation says the scan runs an active scan against the URLs it finds, and offers a safe mode that skips active scanning and performs a baseline scan. Start in safe mode on anything you are unsure about.
OWASP's guidance on API9 adds that production data should not be used in non production deployments, or those deployments should be secured like production.
Accounts and sessions
Create at least two ordinary users and one user per elevated role. Give each some records. A tool with only one token cannot test whether user A reaches user B's data. In ZAP's API scan, an authenticated run uses a user defined in a context file, so you must prepare that file.
Use dedicated accounts with clear names, short lived credentials and no access to real customer data.
Scope and safety
- Write down hosts and paths in scope.
- Exclude endpoints that send email, SMS or payments, or point them at sandboxes. OWASP API4 notes some third party calls are billed per request.
- Set request rate limits for the scan itself.
- Tell the team that owns the environment and agree a window.
- Check that logging and alerting will not drown in scan noise, or tag the scan source.
After the run
Keep the report, the spec version, the target and the scan date together. That record is what a buyer or auditor will ask about later.
Try it yourself
Click through it at your own pace, or open it full screen. Note which inputs the scan setup asks for.
Quick check
Can I scan production?
You can, but plan it. Use safe or read only modes, exclude destructive and billed operations, and agree a window. Staging is the usual first choice.
Why not run with one admin token?
An admin token can reach everything, so it hides authorization flaws. Tests need ordinary roles too.
Safeguard's free scan at gold.safeguard.sh/scan needs no spec and covers dependency risk.
Sources
- ZAP API Scan
- OWASP API4:2023 Unrestricted Resource Consumption
- OWASP API9:2023 Improper Inventory Management
Last reviewed: 19 October 2026.
