API penetration testing for REST, GraphQL and OAuth

API penetration testing verifies whether an attacker can access another user’s data, invoke a privileged function, abuse a business process or exhaust a service through REST, GraphQL, OAuth and related interfaces. A scanner can identify missing headers and known components; it cannot reliably decide who owns an invoice or whether a support role may approve a refund.

This checklist focuses on the controls that create real API risk: inventory, object and function authorisation, tokens, tenant isolation, input processing, rate limits and workflow abuse.

Start with API reconnaissance and inventory

You cannot protect or test an endpoint that nobody knows exists. Collect:

• OpenAPI or Swagger specifications;
• GraphQL schemas and operation registries;
• OAuth and OpenID Connect metadata;
• mobile and web client traffic;
• gateway routes and serverless functions;
• legacy versions, partner endpoints and webhooks;
• administrative and internal interfaces;
• staging or regional deployments exposed to the internet.

Compare documentation with observed traffic. Old /v1/ routes, debug endpoints and temporary partner APIs frequently remain reachable after clients migrate. The OWASP WSTG API reconnaissance guidance provides useful discovery techniques.

For each interface, record the owner, authentication method, data classification, expected consumers, version and retirement date. Inventory is not paperwork: it prevents an unmaintained endpoint from bypassing the controls enforced by the current gateway.

Authentication testing

Authentication tests should cover the full lifecycle, not only a valid login:

• registration and email or phone verification;
• password reset and account recovery;
• MFA enrolment, challenge and recovery codes;
• refresh-token rotation and replay;
• logout and revocation;
• disabled, deleted and locked accounts;
• service accounts and machine credentials;
• concurrent devices and session limits;
• SSO linking and account merging.

Test for user enumeration in status codes, timing and response bodies. Verify that rate limits apply to the actual identity or account, not only the source IP. Distributed attacks can easily bypass an IP-only threshold.

MFA is valuable but does not fix a stolen refresh token or broken authorisation. For deployment guidance, see how to roll out MFA.

BOLA and object-level authorisation

Broken Object Level Authorisation occurs when the API accepts an object identifier but does not verify that the caller may access that object. It is one of the most important categories in the OWASP API Security Top 10.

Test every endpoint that receives an ID in a path, query, body, header, cursor or encoded token. Use at least two users and two tenants. Swap identifiers for:

• profiles, orders and invoices;
• files, exports and attachments;
• tickets and comments;
• projects, organisations and memberships;
• payment methods and transactions;
• asynchronous job IDs;
• notification and webhook configurations.

Random UUIDs reduce guessing but are not authorisation. Ownership and role must be checked on every operation, including indirect references and background jobs.

Function-level authorisation

Broken Function Level Authorisation lets a lower-privileged user call a function intended for an administrator, manager or service. Hiding a button in the front end does not protect the endpoint.

Build a role-action matrix and test direct requests. Look for alternative methods, versioned paths, bulk endpoints and administrative flags. Verify that support staff cannot silently become customers, customers cannot invoke internal exports, and service tokens cannot use human administration routes unless explicitly designed.

Test vertical and horizontal boundaries together. A manager may have permission to approve refunds, but only within their organisation and only below an assigned limit.

Property-level authorisation and mass assignment

APIs often bind JSON directly to an internal object. Attackers add fields that the UI never sends: role, tenantId, verified, price, ownerId, status or creditLimit.

Use explicit input schemas and allowlists. Separate request models from database entities. Test nested objects, arrays, PATCH semantics, duplicate keys and alternative content types. Also check excessive data exposure: a response may contain internal notes, password-reset state, access-control fields or personal data not displayed by the client.

JWT validation checklist

A JWT is a signed container, not an automatic security guarantee. Verify:

• the algorithm is explicitly allowed;
• signatures are always validated;
• iss, aud, exp, nbf and required claims are checked;
• keys are selected safely and refreshed predictably;
• a token for one service is rejected by another;
• role and tenant claims cannot become stale after account changes;
• logout and incident response can revoke meaningful access;
• tokens are not leaked in URLs, logs or analytics;
• clock-skew tolerance is bounded;
• unsigned or algorithm-confusion variants fail.

Do not place confidential data in a JWT merely because it is encoded. The payload is normally readable by the holder. Short-lived access tokens and controlled refresh-token rotation reduce the impact of theft.

OAuth 2.0 and OpenID Connect

OAuth security depends on exact flow validation. Test redirect URI matching, state binding, PKCE, nonce handling, token audience, consent and client type. Look for open redirects, code leakage, mix-up between providers and account linking based on an unverified attribute.

Important questions include:

• Is the authorisation code bound to the client and redirect URI?
• Is PKCE required for public clients?
• Can a code or token be replayed?
• Does the resource server reject tokens minted for another audience?
• Can an attacker link their identity provider account to a victim account?
• Are scopes minimal and understandable on the consent screen?
• Are refresh tokens rotated and invalidated after suspicious reuse?

The resource server must perform its own validation. Trusting that the gateway “probably checked the token” creates fragile architecture.

REST-specific tests

REST APIs need consistent behaviour across methods and representations. Test:

• GET, POST, PUT, PATCH and DELETE authorisation separately;
• method override headers and unexpected verbs;
• content-type confusion and parser differentials;
• pagination, sorting and filtering abuse;
• bulk operations and partial failure;
• idempotency keys and replay of transactions;
• file upload, download and range requests;
• cache behaviour for personalised responses;
• path normalisation and encoded separators;
• server-side requests to user-controlled URLs.

A secure GET handler does not imply that PATCH enforces the same ownership check. Test each operation and version.

GraphQL penetration testing

GraphQL presents a single endpoint but a large logical attack surface. Obtain the schema through authorised documentation or introspection where available. Test:

• resolver-level object and field authorisation;
• mutations hidden from the ordinary UI;
• aliases and batching that bypass rate limits;
• query depth, breadth, recursion and cost;
• node IDs and global object lookup;
• subscriptions and cross-tenant events;
• error messages and schema disclosure;
• nested access that bypasses top-level checks.

Disabling introspection in production may reduce easy discovery, but it does not fix insecure resolvers. Authorisation belongs in shared business logic or every relevant resolver path.

Cost controls should evaluate the actual query plan. Limiting the number of HTTP requests is ineffective when one request contains hundreds of aliases or an expensive nested query.

Rate limiting and resource consumption

Rate limits must reflect the protected resource and business action. Apply appropriate limits by account, tenant, credential, device and global service capacity—not solely by IP.

Test login, recovery, OTP, search, export, file conversion, report generation, GraphQL queries, AI-backed functions and webhooks. Look for asynchronous amplification: one small request may enqueue expensive work or trigger many downstream calls.

The system should return predictable errors, avoid leaking internal capacity and preserve service for other tenants. Monitor cost as well as request count.

Business-logic abuse

Business logic is where manual testing creates the greatest difference. Build workflows and try to violate their assumptions:

• skip a required approval step;
• repeat a one-time refund or promotion;
• change price or currency between stages;
• race two requests against the same balance;
• act on an expired quote;
• approve your own request;
• split a transaction to avoid a limit;
• reorder state transitions;
• reuse an idempotency key across identities;
• exploit a discrepancy between mobile, web and partner APIs.

Controls should enforce invariants on the server and within a transaction. A front-end sequence diagram is not an access-control system.

Webhooks and outbound integrations

Verify webhook signatures, timestamps, replay protection, key rotation and event ownership. The receiver should not trust a source IP alone. Test duplicate and out-of-order delivery because legitimate systems retry events.

For outbound webhooks and URL import features, test SSRF protections. Resolve and validate destinations safely, block internal and metadata ranges, control redirects and restrict protocols. DNS can change after validation, so design must account for rebinding and resolution timing.

Error handling, logging and sensitive data

Responses should avoid stack traces, SQL fragments, internal hostnames, secrets and unnecessary personal data. At the same time, server logs need enough context to investigate abuse: actor, tenant, action, target, decision and correlation ID.

Never log access tokens, authorisation codes, passwords or full sensitive payloads. Test tracing, gateways, observability platforms and support exports because secrets often leak outside the application log.

A practical API pentest process

1. Inventory endpoints, versions, roles and data flows.
2. Prepare accounts for every role and at least two tenants.
3. Establish authenticated baseline requests.
4. Test authentication and token lifecycle.
5. Build object, property and function authorisation matrices.
6. Test input, parsers, files and server-side requests.
7. Evaluate rate limits and resource consumption.
8. Model and abuse critical business workflows.
9. Review logs and detection with the owner.
10. Report reproducible evidence and retest fixes.

Link findings to the current OWASP API categories where useful, but do not let a checklist limit exploration. Architecture-specific risks and business invariants often produce the highest impact.

What to provide before testing

The tester needs specifications, environments, accounts, tenant data, OAuth client details, high-risk workflows and a technical contact. Indicate prohibited production actions and prepare safe objects for destructive tests. Our penetration test preparation guide provides a broader checklist.

A good report states which endpoints and roles were actually covered, not only that the “API was tested”. Each issue should identify the failed control and the correct enforcement layer. Retesting must include variants to confirm that the root cause is fixed.

API security is primarily about authority: who may perform which action, on which object, in which state and at what rate. If you need an independent REST, GraphQL or OAuth assessment, contact Breachroad with your specification and role model.