Ask an API security testing vendor how the tool finds broken authorization across users, how it discovers undocumented endpoints, and what it does in your pipeline. Use the OWASP API Security Top 10 (2023) as your checklist, since it names the flaws that matter. Run a trial on your own API before you sign anything.
What does OWASP say matters most?
The 2023 list is: API1 Broken Object Level Authorization, API2 Broken Authentication, API3 Broken Object Property Level Authorization, API4 Unrestricted Resource Consumption, API5 Broken Function Level Authorization, API6 Unrestricted Access to Sensitive Business Flows, API7 Server Side Request Forgery, API8 Security Misconfiguration, API9 Improper Inventory Management, and API10 Unsafe Consumption of APIs.
Notice that four of the top five are about authorization and authentication. Tools that only fuzz inputs for injection will miss the biggest category.
What should you ask?
Authorization (API1, API3, API5)
- How do you test whether user A can read user B's objects? Do you need two or more test identities, and can you manage them through our login flow?
- Do you check individual fields as well as whole objects, for example a response that returns too many properties?
- Do you test admin-only functions with a normal user token?
Authentication (API2)
- Which authentication schemes do you support, such as OAuth flows, API keys and session cookies, and how do you keep tokens fresh during long scans?
Resources and flows (API4, API6)
- How do you test for missing rate limits and unbounded responses without taking down a shared environment?
- Can you model a business flow, such as a purchase or a signup, rather than only single requests?
Server side request forgery (API7)
- How do you test endpoints that fetch URLs, and where do your probes go so they stay safe?
Inventory and configuration (API8, API9)
- Can you find endpoints missing from our specification, old versions and forgotten hosts, or do you only test what we give you?
- How do you import specifications, and what happens when the spec and the running service disagree?
Third party calls (API10)
- Do you check how our API handles data it receives from other services?
Operations
- Where does it run, and where do our requests and responses go? Can it run inside our network? What does it store?
- How do findings reach developers: a pull request comment, a ticket, a pipeline gate? What is the false positive rate on a sample we choose?
What are the honest limits?
Automated testing finds patterns. It struggles with business logic that only your team understands, such as who may refund what. Budget for a human review of the highest risk flows. Scanning also depends on coverage: an endpoint the tool never sees is never tested, which is why the inventory questions come early.
Safeguard shows dynamic web application scanning in a demo, which you can use to see what a scan report looks like before you compare tools.
Open the full version at /demos/dast-web-app-scan.
What to do
- Pick two or three vendors and send each the same questions in writing.
- Prepare a staging API with seeded authorization bugs, and keep the list secret.
- Run each tool against it and count what each finds and misses.
- Check what each tool needs from you: identities, specs, network access.
- Choose on results and fit with your pipeline, not on the demo.
Quick check
Is a web vulnerability scanner enough for APIs?
Often not. API risks lean on authorization and business logic, which need multiple identities and knowledge of flows, so ask how each tool covers them.
What is API9 Improper Inventory Management?
It covers APIs you forgot you expose, such as old versions and undocumented hosts. A tool that only tests documented endpoints cannot cover it.
Sources
Last reviewed: 18 October 2026.
