API Penetration Testing: A Practical Guide

API penetration testing is the methodical, authenticated testing of your API endpoints for authorisation flaws, broken authentication, logic abuse and injection — the issues that lead to real data breaches. APIs now carry most application traffic and most application data, yet they are frequently tested less rigorously than the web frontends sitting on top of them. This guide covers how API testing differs from web testing, what a good test covers, and how testing works when there is no documentation.

Why API testing differs from web application testing

An API has no UI to crawl, which quietly breaks most automated tooling: a scanner pointed at an API base URL sees almost nothing. The differences run deeper than tooling, though:

• Everything is exposed directly. Object IDs, parameters and full data structures appear in every request and response — no UI hides them. What the frontend chooses not to display, the API often still returns.
• Authentication is token-based. JWTs, API keys and OAuth flows replace cookies and login forms, bringing their own failure modes: weak signing, missing expiry, tokens that survive logout, keys committed to repositories.
• The attack surface is wider than the current app. Versioned routes (/v1/ still alive behind /v3/), mobile-only endpoints and partner integrations all count, whether or not anything links to them.
• Machine-readable responses make exploitation fast. Enumerating ten thousand records through an API is a ten-line script.

This is why a web app test that merely touches the API through the browser is not an API test. The API needs to be enumerated and attacked as a target in its own right.

The OWASP API Security Top 10

We structure API testing around the OWASP API Security Top 10 (2023), which reflects where API breaches actually come from:

• API1 — Broken Object Level Authorisation (BOLA). Change an ID, get someone else's data. The most common and most damaging API flaw; we cover it in depth in our BOLA and IDOR guide.
• API2 — Broken Authentication. Weak token validation, missing expiry, credential stuffing against login endpoints, JWT algorithm confusion.
• API3 — Broken Object Property Level Authorisation. The API returns fields the caller should not see, or accepts fields they should not set — mass assignment turning "role": "admin" in a profile update into privilege escalation.
• API4 — Unrestricted Resource Consumption. No rate limits, no pagination caps, no payload size limits: denial of service and cost amplification.
• API5 — Broken Function Level Authorisation. Regular users calling admin endpoints — BOLA's sibling at the function level.
• API6 — Unrestricted Access to Sensitive Business Flows. Legitimate flows abused at machine speed: automated purchasing, referral farming, mass account creation.
• API7 — Server-Side Request Forgery. URL parameters that make your server fetch attacker-chosen destinations, including cloud metadata services.
• API8 — Security Misconfiguration. Verbose errors, permissive CORS, missing TLS, debug endpoints left enabled.
• API9 — Improper Inventory Management. Forgotten API versions and shadow endpoints running old code with new data.
• API10 — Unsafe Consumption of APIs. Trusting third-party API responses without validation.

Notice what dominates the list: authorisation and logic, not injection. That is precisely the territory automated scanners cannot assess, because deciding whether user A should see object B requires business context, not signatures.

Testing without a spec

An OpenAPI spec or Postman collection is genuinely helpful — it gives immediate, complete endpoint coverage. But no documentation does not mean no test. When there is no spec, we build one:

• Proxy the clients. Running the web frontend and mobile apps through an intercepting proxy captures every endpoint they actually call.
• Mine the JavaScript. Frontend bundles contain route definitions and API paths, including endpoints for unreleased or admin features.
• Decompile mobile apps. APKs and IPAs yield hardcoded endpoints, and sometimes keys.
• Enumerate the rest. Wordlist-based discovery of paths, parameters, HTTP methods and old versions (/v1/, /v2/) that documentation forgot — which is exactly how attackers find the API9 endpoints you forgot too.

The result is a working collection of the real attack surface — often broader than the official docs would have been.

What a good API pentest looks like in practice

A quality engagement runs roughly: scoping and access setup, with at least two test accounts per role (and per tenant, for multi-tenant products); endpoint inventory using the techniques above; a full authorisation matrix testing every object reference and function across accounts, roles and tenants; authentication and token analysis; business flow abuse and rate limit testing; injection and input handling across all parameters; then a report with reproduction steps and specific remediation advice, and a retest of fixes. If your stack includes GraphQL, it needs its own techniques on top — see our guide to GraphQL security testing.

With us, an API penetration test typically runs 5–10 days at AU$8,000–18,000 depending on endpoint count and complexity, with a fixed quote within one business day of a free scoping call and a free retest of fixed issues within 90 days.

FAQ

Do we need to provide API documentation before a test?

No — helpful, but not required. A spec or Postman collection buys coverage speed, but we routinely reconstruct API surfaces from clients, JavaScript and enumeration. Undocumented APIs are frequently where the best findings live.

Can you test our production API?

Yes, with agreed safe-testing rules — though a staging environment with production-like data is preferred, since authorisation testing means deliberately attempting cross-account access and rate limit testing can be noisy.

Is an API test separate from a web application test?

They are distinct disciplines that are often sensibly combined, since most web apps are frontends over APIs. What matters is that the API is enumerated and tested directly — not just exercised through the browser.

If your API handles customer data and has never been properly tested, get in touch — a short scoping call and you will have a fixed quote within one business day.