API exploitations are everywhere. In 2021, 91% of organizations faced challenges related to APIs, and most of the time rogue endpoints are the root cause.
Why APIs need their own security pass
A web scan that crawls pages will miss most API risk, because the attack surface is the request itself: object identifiers, tokens, scopes, and JSON bodies. Undocumented endpoints and old versions left running are a common route in.
OWASP ZAP gives you a proxy, a scanner, and a scripting engine in one place, which makes it a practical starting point for teams without a dedicated security tool budget.
Setting up ZAP for an API target
- Import the API definition (OpenAPI, SOAP, or GraphQL) so ZAP knows the endpoints instead of guessing them.
- Configure authentication and a session token so the scan runs as a real user, not an anonymous visitor.
- Set the target scope so the spider stays inside the domain you are permitted to test.
- Choose a scan policy: start with the baseline passive rules, then enable active rules deliberately.
Running the scan and reading the output
A passive scan reviews traffic as it passes through the proxy and flags header, cookie, and information-disclosure issues without touching the application. An active scan sends crafted requests and will find injection, traversal, and misconfiguration problems, so run it only against a non-production environment.
Treat every finding as unconfirmed until you have reproduced it by hand. Scanner output contains false positives, and a report full of them destroys the credibility of the real issues sitting next to them.
What scanners cannot find
Authorisation logic is the gap. Broken object-level authorisation, privilege escalation, and business logic abuse all require a tester who understands what the endpoint is supposed to allow. The reliable manual check is simple: capture a request as one user, swap in another user’s identifier and token, and confirm the API answers with a refusal rather than data.
Scripting in ZAP (JavaScript, Zest, Python, and others) lets you encode those checks as repeatable rules once you have found them, and run them on every build.
[ Key takeaways ]
- Import the API definition; do not rely on crawling.
- Authenticate the scan or you only test the public surface.
- Verify every automated finding by hand before reporting it.
- Test authorisation manually, then script the check for regression.
Frequently asked questions
Can ZAP test REST and GraphQL APIs?
Yes, ZAP can test REST and GraphQL APIs. Import the API definition, whether OpenAPI, SOAP or GraphQL, so ZAP knows the endpoints instead of guessing them, then configure authentication and a session token so the scan runs as a real user. Without authentication you only test the public surface of the API.
What does ZAP not catch?
ZAP does not catch authorisation logic flaws well. Broken object-level authorisation, privilege escalation and business logic abuse all need a tester who understands what each user should and should not be able to do. Test authorisation manually, verify every automated finding by hand, then script the authorisation checks for regression.
Let’s discuss the opportunities
Talk to QAonTOPYour dev team needs a solid QA partner
Free one-week POCNDA before accessA QA lead replies the same working day