API Testing Guide
API security testing finds flaws in the interfaces applications use to talk to each other. It differs from web testing because there is no UI to guide you, authorisation flaws dominate over injection, and documentation plus captured traffic drive discovery. The single most important thing to test is object level authorisation.
Why API testing is different
Web app testing has a UI that shows you the features. An API has none. You work from documentation, captured traffic, and inference. And the vulnerability profile shifts: authorisation flaws dominate, because APIs expose objects directly with identifiers in every request.
The OWASP API Top 10, the priorities
| Risk | Priority |
|---|---|
| Broken object level authorisation | Highest, test first |
| Broken authentication | High |
| Excessive data exposure | High |
| Mass assignment | Medium |
| No rate limiting | Medium |
The top risk, BOLA, is covered fully in BOLA explained.
The methodology
- Map the API from documentation and captured traffic
- Understand the authentication and authorisation model
- Test object level authorisation with two accounts
- Test authentication: tokens, sessions, JWT flaws
- Check for excessive data exposure in responses
- Test mass assignment by adding privileged fields
- Check rate limiting on sensitive actions
The tools
| Tool | Use |
|---|---|
| Burp Suite | Intercept, modify, replay, the core tool |
| Postman | Exploring and documenting endpoints |
| A proxy | Capturing traffic from mobile or SPA clients |
Postman is great for understanding an API; Burp is where the actual testing happens. Setup in the Burp Suite tutorial.
Testing what has no documentation
Often you get an API with no docs. Capture the traffic from the app that uses it, whether a mobile app or a single page web app, and reconstruct the endpoints from what you see. Hidden and undocumented endpoints are frequently where the bugs are.
GraphQL is its own thing
GraphQL APIs need specific tests: introspection left on in production, query depth and complexity limits, batching abuse for brute forcing, and per resolver authorisation rather than per endpoint.
Test authorisation first, always. On APIs it is both the most common and the most severe flaw. Two accounts and a swapped identifier find more than any scanner.
Practise this
Practise on deliberately vulnerable APIs, testing object level authorisation on every endpoint. Free API challenges on Hacklido. Structured path in the API security course.
Enroll in API Security
Live instructor led training with hands on labs and a verifiable certificate. Or start free on Hacklido.
Enroll in API Security