API Security Testing: A Complete Guide for SaaS Teams
For most modern products, the API is the product. Web frontends, mobile apps, integrations and partners all talk to it. Attackers know that APIs often enforce fewer checks than the UI, and that one missing authorisation check can expose every customer's data.
Why APIs need dedicated testing
- The UI hides, the API exposes. A button may be hidden from a user, but the endpoint behind it still responds.
- APIs return more than the UI shows. Responses often include fields the frontend ignores, such as internal IDs, emails or flags.
- APIs grow fast. New endpoints ship weekly, each with its own authorisation logic.
- Old versions linger.
/v1stays live long after/v2launches, often with weaker checks.
Step 1: Build an inventory
You cannot test what you do not know exists. Collect:
- OpenAPI or Swagger specifications, GraphQL schemas and Postman collections.
- Endpoints observed in frontend and mobile traffic.
- Documented and undocumented versions.
- Internal endpoints reachable from the internet.
Step 2: Test authentication
- Do all endpoints require authentication, unless intentionally public?
- Are tokens validated properly, including signature, expiry and audience?
- Are API keys scoped, rotatable and never exposed in client code?
- Are there rate limits on authentication endpoints?
Step 3: Test authorisation, the most important step
Use at least two users in two tenants, plus users with different roles.
- Object level (BOLA): can user A access user B's objects by ID?
- Property level (BOPLA): can users read or write fields they should not, such as
roleorprice? - Function level (BFLA): can a normal user call admin endpoints?
- Tenant isolation: can tenant A see or modify tenant B's data?
Step 4: Test input handling
- Injection in every parameter, including JSON bodies, headers and GraphQL arguments.
- Mass assignment by adding unexpected fields.
- Type confusion, such as arrays where strings are expected.
- SSRF in parameters that accept URLs.
Step 5: Test resource consumption and abuse
- Rate limits on expensive operations and sensitive flows.
- Pagination limits, such as requesting a page size of 100,000.
- GraphQL query depth and complexity limits.
- Abuse of business flows, such as mass account creation or scraping.
Step 6: Check data exposure
- Responses containing excessive fields.
- Verbose errors leaking stack traces or queries.
- Sensitive data in URLs, which ends up in logs.
API testing checklist
| Area | Key question |
|---|---|
| Inventory | Do we know every endpoint and version? |
| Authentication | Is every endpoint protected and tokens validated? |
| Object authorisation | Can users access others' objects? |
| Property authorisation | Can users read or set restricted fields? |
| Function authorisation | Can users call admin functions? |
| Input | Is input validated and safely handled? |
| Consumption | Are rate and size limits enforced? |
| Exposure | Do responses leak unnecessary data? |
Automating API security testing
Manual API testing is valuable but slow, and APIs change constantly. SecurityInfinity's API agent discovers endpoints, tests them with multiple identities for BOLA, BFLA and property-level flaws, checks injection and limits, and verifies every finding with evidence and a fix. Start free.
Frequently asked questions
What is the most common API vulnerability?
Broken object level authorisation, where users can access other users' objects by changing an ID. It is first in the OWASP API Security Top 10.
Do API gateways make APIs secure?
Gateways help with authentication, rate limiting and logging, but object-level authorisation must be enforced in the application.
How is API testing different from web app testing?
It focuses more on authorisation per endpoint, data exposure and machine-to-machine access, without relying on the UI to reveal functionality.