To cut false positives in API security testing, triage by OWASP API category. Authorization findings need a test with two real users, SSRF findings need evidence that your server made the outbound call, and resource consumption findings need measurements. A generic "confirm and suppress" workflow wastes time and hides real problems.
Why do API scanners produce so much noise?
API flaws are mostly about logic, not syntax. An endpoint that returns another customer's invoice looks like a normal 200 response to a tool that does not know who owns the invoice. So scanners infer, and inference produces false positives in one direction and missed flaws in the other.
The OWASP API Security Top 10 (2023) is a useful sorting key because each category fails differently. Its ten items are broken object level authorization, broken authentication, broken object property level authorization, unrestricted resource consumption, broken function level authorization, unrestricted access to sensitive business flows, server side request forgery, security misconfiguration, improper inventory management and unsafe consumption of APIs.
Below, what to ask before you accept or dismiss a finding.
Authorization categories (API1, API3, API5)
Broken object level, property level and function level authorization are the most common high-impact items and the hardest for tools to judge. A tool flags "an ID in the URL can be changed" or "an admin route responded."
How to triage: reproduce with two accounts in the same test tenant. User A requests user B's object. If the API returns it, the finding is real. If it returns 403 or an empty result, it is a false positive, and you can write the exact two-user test as a regression check. For function level, call the admin route as an ordinary user. A 200 with an error message in the body still needs a read.
Authentication (API2)
Noise often comes from test environments with relaxed settings. Confirm the finding against the configuration production uses. Check whether the weak behavior is in the code path or only in the test fixture. If your scanner cannot log in as each role, its authenticated results are weak and its unauthenticated results may be inflated.
Resource consumption (API4)
A tool may flag "no rate limit" because it did not see a limit header. The limit may sit at a gateway the scanner bypassed. Measure: send a controlled burst from a test client and see whether it is throttled. Keep bursts small, in a test environment you own.
SSRF (API7)
A scanner submits a URL and sees a slow response. That is a hint, not proof. Real evidence is a log line on a server you control showing the API made the request, or the API returning content from an internal address. Without that, mark as unconfirmed and keep it in a low-priority queue.
Misconfiguration, inventory and unsafe consumption (API8, API9, API10)
Missing headers are cheap to verify and often legitimate findings, but they are rarely urgent. Inventory findings (old API versions, undocumented routes) are usually accurate but need an owner, not a patch. For unsafe consumption, check whether your API trusts data from a third party without validation. That needs a code read, not a scanner verdict.
How do you build a feedback loop?
- Record the reason for every dismissal in one sentence, tied to the category.
- Turn confirmed true positives into automated tests.
- Turn recurring false positive patterns into scanner configuration, such as skipping a known gateway header check.
- Review dismissals quarterly. A dismissal that is wrong costs more than a thousand noisy findings.
We have no verified documentation for Safeguard's own API security testing, so this post stays tool-neutral. For its SAST and DAST, the docs say no triage or suppression workflow is described on that page, so confirm the workflow in your own tenant.
What to do
- Give your scanner credentials for at least two users per role in a test tenant.
- Sort findings by OWASP API category before triage.
- Prove authorization findings with a two-user request.
- Require log evidence for SSRF claims.
- Write a one line reason for every dismissal and review them quarterly.
Quick check
Which test confirms broken object level authorization?
Request one user's object with another user's credentials in a test tenant. If the data returns, the flaw is real.
Is a missing rate limit header always a finding?
No. The limit may be enforced at a gateway or elsewhere. Measure with a small controlled burst in a test environment.
Sources
Last reviewed: 18 October 2026.
