API Penetration Testing: Methodology and Checklist

Most modern applications are APIs wearing a user interface. The mobile app, the single-page frontend, the partner integration: all of them are thin clients talking to the same backend endpoints. Yet when companies scope a penetration test, the API is often an afterthought, tested only as far as the UI happens to exercise it.

That gap is exactly where attackers live. This guide is the methodology and the checklist for testing an API properly, built around the OWASP API Security Top 10 (2023), with the tests to run for REST and GraphQL and how to scope the engagement.

What is API security testing?

API security testing is the practice of checking an API’s endpoints directly, from the specification rather than through a user interface, for authorization, authentication, input-handling, and business-logic flaws. Because the client is not a security boundary, every rule the API is supposed to enforce has to be tested against the server itself. Automated tools help with discovery and known patterns; the flaws that cause breaches, above all broken authorization, require a human who understands what each endpoint is meant to allow.

Why APIs need their own testing approach

A traditional web application test follows the interface: log in, click through the workflows, tamper with what the browser sends. An API has no interface to follow. Its full surface is defined by its specification, and often by endpoints that exist but never made it into any documentation.

Three things make APIs different from a testing perspective:

• The client is not a security boundary. Anything your mobile app or frontend enforces can be bypassed by calling the API directly. Validation, rate limits, and access rules only count if the server enforces them.
• Authorization is per-object, not per-page. A web app can hide a button. An API has to decide, on every single request, whether this token is allowed to touch this record. Getting that decision wrong at scale is the most common critical finding we see.
• Business logic is exposed directly. APIs surface operations in raw form: transfer funds, change role, apply discount. Chaining legitimate calls in an illegitimate order is often more damaging than any injection flaw.

The OWASP API Security Top 10 (2023) checklist

The OWASP API Security Top 10, 2023 edition, is the reference standard. It is a separate list from the web application OWASP Top 10, built for the way APIs fail. Work through every category on every engagement. The table gives the test to run for each; the notes below expand the ones that produce most of the serious findings.

ID	Category	What to test
API1:2023	Broken Object Level Authorization (BOLA)	Change the object ID in each request and try to read or edit another user’s or tenant’s record. Requires two accounts per role.
API2:2023	Broken Authentication	Token validation and expiry, revocation on password change, JWT signature and algorithm handling, credential stuffing on login and reset.
API3:2023	Broken Object Property Level Authorization	Send extra properties the client should not set (mass assignment) and check whether the response returns fields the caller should not see.
API4:2023	Unrestricted Resource Consumption	Send requests without rate limiting, large payloads, and expensive queries; check limits on login, search, and export.
API5:2023	Broken Function Level Authorization	Call admin and privileged endpoints as an ordinary user; change the HTTP method; reach functions that were hidden rather than protected.
API6:2023	Unrestricted Access to Sensitive Business Flows	Automate a sensitive flow (checkout, signup, booking) to see whether it can be abused at scale without a compensating control.
API7:2023	Server Side Request Forgery (SSRF)	Supply URLs the server will fetch and try to reach internal services, cloud metadata, or the loopback interface.
API8:2023	Security Misconfiguration	Check CORS, missing security headers, verbose errors, unpatched components, and unnecessary HTTP methods.
API9:2023	Improper Inventory Management	Find shadow, deprecated, and staging API versions; compare live endpoints against the documentation.
API10:2023	Unsafe Consumption of APIs	Test how the API handles data from the third-party services it consumes, including redirects and malformed responses.

API1, Broken Object Level Authorization, is the one to spend the most time on. Change an ID in the request and read someone else’s data. Simple to describe, endemic in practice, and invisible to scanners because the response is a valid 200. You can only prove it with two accounts per role, so you have a “user B” whose data “user A” should not reach.

API2, Broken Authentication, covers weak token handling, missing revocation, tokens that survive a password reset, and endpoints that skip authentication entirely. Test the JWT: try the none algorithm, a weak signing key, and an expired token.

API3, Broken Object Property Level Authorization, merges the old “excessive data exposure” and “mass assignment” items. Send fields the client should never set, such as role or isAdmin, and check whether the endpoint returns object properties the caller should not see.

API5, Broken Function Level Authorization, is regular users reaching admin endpoints that were “hidden” rather than protected. Enumerate admin routes and call them with an ordinary token.

None of these are found reliably by automated tools. They require a human who understands what the application is supposed to allow, then proves what it actually allows. For the fixes behind each category, see our OWASP API Security Top 10 explainer.

Testing methodology, step by step

A thorough API engagement runs in this order:

1. Inventory the surface. Load the OpenAPI or GraphQL schema, or the Postman collection, and confirm it against live traffic. Note the endpoints that are reachable but undocumented.
2. Map authentication. Understand how tokens are issued, refreshed, and revoked, and capture a valid token for each role and tenant.
3. Build the authorization matrix. For every endpoint and object, record who should have access, then test each cell: replay each request as every other role and as a second user of the same role.
4. Attack input handling. Injection, SSRF, and deserialization on parameters, headers, and bodies, confirming exploitability rather than reporting a reflected string.
5. Abuse the business logic. Reorder steps, replay them, race them, and change quantities and prices to break workflows the API assumes will run in one sequence.
6. Push on limits and inventory. Test rate limiting on sensitive flows, then hunt for shadow and deprecated versions that skipped the current controls.
7. Chain and prove. Combine findings into the path an attacker would use, then write each up with evidence and reproduction steps, in the structure of our penetration testing report template.

Testing GraphQL APIs

GraphQL moves the attack surface without removing it. Beyond the checklist above, a GraphQL test adds:

• Introspection. If introspection is enabled in production, the full schema is available to an attacker. Pull it and map every query and mutation.
• Authorization per field. Authorization has to be enforced on each field and resolver, not just each endpoint. Test whether a low-privilege token can select fields it should not see.
• Nested query and alias abuse. Deeply nested queries and repeated aliases in one request can exhaust resources; test depth and complexity limits.
• Batching attacks. Sending many operations in one request can bypass rate limits on login or one-time-code endpoints.

Our guide to GraphQL security testing walks through each of these attacks, plus endpoint discovery and CSRF, with how to test for them.

Scoping an API penetration test

A useful API test starts with a complete inventory. When you scope an engagement, expect to provide:

• The API specification (OpenAPI/Swagger, GraphQL schema, or Postman collection).
• Test accounts at each privilege level, ideally two per role so cross-tenant and cross-user access can be proven.
• A non-production environment where destructive tests are safe, or clear rules of engagement for production.
• Any partner or internal endpoints that are reachable but undocumented.

Two accounts per role is the detail most teams miss. Proving that user A can read user B’s records requires a user B. Scope decides price: our API penetration testing services start at $4,000 for a single API of roughly a dozen endpoints, with the full size bands and what fits each one on the API penetration testing pricing page.

Tools for API testing

Tools speed up discovery and the repetitive checks; a tester still decides what to try and reads the results.

• Burp Suite. The intercepting proxy where most manual API testing happens: replay, modify, and fuzz requests. See our Burp Suite comparison.
• Postman. Drives an API from its collection, useful for building the request set and the authorization matrix.
• OWASP ZAP. An open-source proxy and scanner that imports an OpenAPI spec and probes each endpoint.
• Kiterunner. Discovers API routes that are live but missing from the documentation.

How often to test

Annually at minimum, and after any significant change to authentication, authorization, or the data model. If your API is the product, as it is for most SaaS companies, treat major version releases as testing triggers too. A retest of remediated findings should be included, so your final report shows fixes verified, not just promised.

Frequently asked questions

What is the difference between API security testing and API penetration testing? API security testing is the umbrella for every method, including automated scanning. An API penetration test is the manual part: a tester attacks the endpoints, proves what is exploitable, and reports it with evidence. This guide is the checklist for that manual test.

Can a scanner test an API on its own? A scanner finds misconfigurations and some injection patterns, but it cannot tell whether one user’s token should reach another user’s object. Broken object level authorization, the top API risk, needs a human with two accounts. Use scanning between tests, not instead of them.

Do you test GraphQL and SOAP as well as REST? Yes. The checklist above applies to all three, with GraphQL adding introspection, per-field authorization, and batching tests, and SOAP adding XML and WSDL-specific checks.

How do we prepare an API for testing? Provide the specification, two test accounts per role and tenant, and a staging environment. Missing accounts and specs are the most common cause of a slow start.

The short version

APIs fail quietly. There is no defaced homepage, just data leaving through an endpoint that answered exactly as designed. Work the OWASP API Top 10 on every endpoint, prove authorization with two accounts per role, and treat undocumented endpoints as part of the surface. To confirm yours are actually shut, scope an API assessment against your real endpoints and get a fixed price with the retest included.