No. A clean API scan means the checks it ran found nothing in the endpoints it reached, as the accounts it used, in the mode it ran. It says little about endpoints it never saw, roles it never tried, or logic it cannot understand. Treat it as one input.
Myth and fact
| Myth | Fact |
|---|---|
| The scan covered the whole API | It covered what was in its spec, crawl or traffic. Documentation can be inaccurate or incomplete, and old versions may hide still-working endpoints |
| No findings means no authorization problems | Authorization checks need at least two ordinary accounts, and role checks need role accounts. A one-account scan cannot find them |
| It tested as a logged-in user | Sessions can expire mid-run and turn the rest into 401 responses |
| It tested the dangerous methods | Safe or passive modes skip attack requests |
| It tests business rules | Usage limits and workflow rules need abuse cases written by someone who knows the rule |
| It covers every API type | Spec-driven tools may skip WebSocket messages, and GraphQL needs schema-aware checks |
What makes a result trustworthy
Ask five questions of every clean report.
- Coverage. How many operations were tested, out of how many known? Compare with your inventory. OWASP's inventory guidance says to keep each host, version and environment listed, and to protect every exposed version.
- Identity. Which accounts were used? Were both users and each role present?
- Session. Was the scan authenticated for the whole run? Look at the share of successful authenticated calls.
- Mode. Passive or active? Were write methods allowed? Which rules were off?
- Gaps. What did the report say it could not test?
A good report answers these without being asked. If it does not, the clean result is unexplained.
What a clean scan is still good for
- Detecting regressions in headers, error handling and exposed details between releases.
- Giving developers fast feedback in CI.
- Producing dated evidence that testing happens on a schedule.
- Confirming that fixes from earlier findings still hold.
None of that is trivial. Just do not describe it as a full assessment.
What to add
OWASP's testing guide treats the main authorization risks as manual-friendly tests built around two accounts. Pair the scanner with a small regression suite for object level and function level checks, usage limits and list endpoints, and with a periodic human review for logic. For risk that matters most, such as payments or personal data, a penetration test adds judgment that automation lacks.
How to say it in a questionnaire
Be exact. "Automated API scans run on every release in a test environment, authenticated as two users and three roles, and a manual review covers business logic" is true and checkable. "Our APIs are fully tested" is not something a scan can show.
Worked example: reading a clean report with five questions
A vendor sends a report for its customer-facing API. The summary says: "Scan complete. 0 high, 0 medium, 2 low findings." The buyer's security reviewer wants to know what that means. Here is how the five questions are applied.
Coverage. The report footer says 64 operations tested. The vendor's public docs list around 90 endpoints. The reviewer asks about the other 26. The vendor replies that 20 are admin routes outside the scan, and six are new since the spec used for the scan was generated. That is a useful answer, and it shows a gap of six routes nobody tested.
Identity. The report lists one account, a standard user. No second user, no admin, no anonymous run. The reviewer notes that object and function level flaws could not have been found by design.
Session. The report does not say. The reviewer asks for the proportion of authenticated requests that succeeded. The vendor sends a log excerpt: 95 percent of requests returned success or an expected status. That is reassuring about session handling.
Mode. The report says active scan, but write methods were disabled "to protect the test environment". Write-path checks are therefore untested.
Gaps. The report has no not-tested section. The reviewer asks for one.
Result of the review.
| Question | Answer from the vendor | Reviewer's reading |
|---|---|---|
| Coverage | 64 of about 90 | Six routes new and untested, admin routes excluded |
| Identity | One standard user | No authorization testing across users or roles |
| Session | 95 percent authenticated | Fine |
| Mode | Active, no write methods | Write paths untested |
| Gaps | Not stated, then supplied | Acceptable once documented |
The reviewer writes: "Automated scan of 64 operations as one standard user, read methods only, no findings above low. Authorization across users and roles and write paths are not covered by this evidence." That sentence is accurate, and it avoids both overstating the report and dismissing it.
Follow-up requests. A second round with two users and an admin account on a seeded environment, including write methods, and an update of the spec to cover the six new routes.
Doing the same for your own reports
Before you send a clean report to a customer or file it for an audit, add a cover note with the five answers. It takes ten minutes. It protects you from the awkward case where a customer later finds a flaw in a route your scan never covered and asks why your report said nothing.
A note on tone
Do not apologize for gaps. Every test has them. Stating them plainly reads as competence. Hiding them reads as either ignorance or evasion, and a careful reviewer will probe until they find the truth anyway.
When to be more or less concerned
Not every clean report deserves the same level of suspicion. A few signals help you decide how hard to push.
Less concerned when the API is small and low risk, the report names its accounts, coverage and mode, previous scans found real issues that were fixed, and a manual review has covered authorization and limits within the last year.
More concerned when the API handles money, health data or personal data, the report is short and generic, the vendor cannot say how many operations were tested, no second account was used, or the finding count has been zero for a long time on a changing API. A system that changes every week and never produces a finding is more likely to have a blind scan than a perfect codebase.
Ask for one extra thing when the risk is high: a short walkthrough of how the team reproduced a past finding. Teams that really test can do this quickly, because they have done it before. Teams that run a tool and file the report usually cannot.
Try it yourself
Open the demo and read the example findings the way the reviewer reads a report: which operations, as which account, in which mode?
Click through it at your own pace, or open it full screen.
Quick check
How many findings should a healthy API scan return?
There is no good number. Judge the coverage, accounts and mode before reading the count. A low count with low coverage is not healthy.
Should I rerun a clean scan with a different tool?
A second tool can add coverage, but a second set of accounts, a better spec or a manual authorization test usually adds more.
What should I do if my clean report is all I have?
Add the cover note with coverage, accounts, session, mode and gaps, and plan the missing tests with dates. A clean report with honest limits is more credible than one without context.
Sources
- OWASP API9:2023 Improper Inventory Management
- OWASP WSTG: API reconnaissance
- OWASP WSTG: API broken object level authorization
- ZAP API scan documentation
Last reviewed: 19 October 2026.
