An API penetration test begins by modelling operations, callers, tokens, objects, tenants and service paths. It then challenges those relationships with controlled requests and follows each effect beyond the first response.

The process is not equivalent to importing an OpenAPI file into a scanner. Specifications accelerate inventory, while human analysis tests authorization, business state, asynchronous behaviour and distributed trust.

A mature engagement keeps three records synchronized: the operation inventory, the identity-and-object matrix and the coverage log. Together they show what could be called, who and what relationships were compared, and which tests were completed, sampled or constrained. Without that traceability, a long finding list still cannot prove that the API’s most important authority boundaries were examined.

The buyer also supplies context that traffic alone cannot reveal: authoritative business records, intended workflow transitions, service ownership and safe operating limits. The tester uses that context to form adversarial hypotheses without allowing documentation to replace independent discovery.

Scope defines the API assurance boundary

The parties list hosts, environments, versions, operations, protocols, roles, tenants, workflows and service access. They define safety, evidence and retest.

Operations or systems outside authority remain excluded and visible. Direct microservice access is not assumed from gateway permission.

  • Base URLs and versions.
  • REST, GraphQL, RPC and events.
  • Identity and tenant matrix.
  • Rules and exclusions.

Readiness proves the test can execute

The provider validates contracts, collections, accounts, tokens, test objects, network paths and monitoring before the main window.

Known owner and foreign objects support authorization tests. Invalid identifiers cannot substitute for a prohibited control case.

  • Machine-readable specifications.
  • Representative payloads.
  • Multiple roles and tenants.
  • Seeded workflow state.

Discovery reconciles declared and observed operations

Testers compare specifications with web and mobile traffic, client artefacts and authorised logs. They identify undocumented, deprecated and alternate routes.

Each discovery is classified by authority and ownership. The operation inventory becomes both a coverage baseline and a change record.

  • Method and normalized path.
  • Version and host.
  • GraphQL or service operation.
  • Reachability and owner.

Authentication and token flows are mapped

The analyst documents issuers, clients, grants, redirects, scopes, audiences, keys and service credentials. It tests issuance, use, refresh, revocation and role change.

A decoded JWT is not an assessment. Validation and authorization are traced through gateway and receiving service.

  • OAuth or OIDC flow.
  • JWT validation context.
  • API keys, signatures or mTLS.
  • Lifecycle and revocation.

Object authorization is compared

Requests are repeated across owner, peer, tenant and privileged identities using known objects. Direct and nested access, lists and bulk operations are included.

Evidence captures caller, token context, object relationship, expected denial and observed final data or effect.

  • BOLA or IDOR comparisons.
  • Cross-tenant isolation.
  • Nested and related objects.
  • Export and batch access.

Function authorization is challenged

Lower roles attempt administrative, approval, configuration and support functions through documented and alternate routes.

Method, version, gateway and direct-service differences are tested where authorised. UI visibility is irrelevant to server authority.

  • Privileged operations.
  • Role and state prerequisites.
  • Bulk and alternate variants.
  • Internal and public routes.

Inputs and resource controls are assessed

The tester exercises structured inputs, filters, parsers, files and downstream requests, validating findings manually.

Rate, pagination, query complexity and expensive jobs are tested within agreed ceilings. Denial-of-service stress requires separate approval.

  • Injection and unsafe parsing.
  • File and server-side requests.
  • Pagination and enumeration.
  • Bounded resource use.

Business workflows are tested across calls

Critical state machines are exercised for sequence bypass, replay, idempotency, concurrency, amount changes and stale authority.

The analyst verifies the authoritative downstream result, not only status code. Workflows may cross clients, workers and provider callbacks.

  • Approval and entitlement.
  • Payment and refund.
  • Retry and duplicate effects.
  • Cancellation and compensation.

GraphQL and alternate protocols receive native tests

GraphQL coverage maps queries, mutations, fields, resolvers, batching, cost and federation. gRPC and events use service and message contracts.

The provider avoids treating one transport endpoint as one security operation. Identity and object context remain central.

  • Resolver-level authorization.
  • Aliases and batching.
  • Subscriptions and streams.
  • Event producer-consumer trust.

Gateway and microservice trust is traced

Testing examines trusted headers, identity propagation, workload privileges, direct routes and downstream policy.

Edge validation does not prove service authorization. Source- or architecture-assisted evidence may be used when internal access is restricted.

  • Gateway transformation.
  • Service identity.
  • Tenant context propagation.
  • Direct service bypass.

Asynchronous results are followed

Webhooks, queues, exports and jobs are tested for authenticity, replay, ordering, ownership and output protection.

A 202 Accepted response is only the beginning. The tester observes the worker and final artefact or business state.

  • Job and output access.
  • Webhook binding.
  • Retry and duplicate delivery.
  • Stale privilege.

Findings and coverage are quality reviewed

Confirmed issues include reproducible requests, identities, object or state context, impact, severity, root cause and remediation.

A coverage matrix distinguishes completed, sampled, constrained and untested operations. Critical risk is escalated before the final report.

  • Control comparison.
  • Safe evidence.
  • Systemic variants.
  • Explicit limitations.

Remediation targets enforcement patterns

Engineering fixes shared authorization, token, workflow or validation controls rather than only the demonstrated route. The provider clarifies evidence without designing the entire solution.

Retesting verifies the original proof and representative methods, versions, identities and service paths. The closure record retains residual constraints.

  1. Fix the root enforcement point.
  2. Add automated regression controls.
  3. Deploy the intended build.
  4. Retest the pattern and final effect.

Use the OWASP API Security Top 10 2023 for API risk themes, NIST SP 800-115 for assessment process and the OAuth 2.0 Security Best Current Practice when relevant to token flows.

Expect identity-to-effect traceability

Professional API testing connects a caller and token to an object, function, state and downstream result. That chain turns raw traffic into security evidence.

WIMD preserves the same chain through scope, testing, reporting and retest so buyers can understand both confirmed risk and remaining uncertainty.

At closure, reconcile the final operation inventory with the tested identities, service paths and accepted limitations. Store that evidence beside the release record so future API changes can be compared against the assessment baseline instead of assuming that an old report covers new authority and workflow behaviour across every client, tenant, deployed service and environment in the production architecture.