An API inventory is not yet an attack-surface model. A list of routes says where requests can be sent; it does not explain which identities can send them, which objects they affect, which business states they change, or which services trust the result. Modern API risk appears in those relationships.

Gateways, REST and GraphQL endpoints, mobile backends, partner APIs, webhooks, queues and internal services may expose the same business capability through different paths. If assessment scope follows only the published specification, it can miss legacy versions, direct-service routes, background consumers and workflows that become dangerous only when actions are chained.

A useful map connects technical operations to security invariants. It identifies the actor, credential, tenant, object, action, state and authoritative outcome for every critical flow. That model gives penetration testers a defensible denominator for coverage and gives engineers a way to remediate shared causes rather than isolated URLs.

Know when an endpoint list is giving false confidence

Teams often begin with OpenAPI files or gateway exports. Those are valuable inputs, but they can omit dynamically generated routes, older versions, GraphQL operations, callbacks and service-to-service APIs. They also rarely describe object ownership, delegated authority or the sequence required to reach a sensitive state.

The gap becomes visible when testers receive one administrator account, one standard account and a route count. That setup cannot prove horizontal authorization, tenant isolation, lifecycle restrictions or workflow abuse. The assessment needs paired identities and known objects as much as it needs requests.

  • Different web, mobile and partner clients share a backend but use different tokens or gateways.
  • Multiple roles or tenants can act on the same object types and bulk operations.
  • Queues, webhooks and background jobs complete actions after the initiating request.
  • Internal services trust gateway headers or shared machine credentials.
  • Specifications, gateway routes and production telemetry disagree about the active surface.

Reconcile every source of API truth

Combine design-time and runtime evidence. Specifications, source routes, gateway configuration, client traffic, service meshes, logs and cloud inventories each reveal different parts of the surface. Differences are not administrative noise; they are test hypotheses about shadow, orphaned or bypass paths.

Normalise hostnames, versions, methods, operations and owners, but preserve path distinctions that change controls. Mark whether the route is public, partner, mobile, administrative, internal or asynchronous. Record the authentication mode and the component that makes the final authorization decision.

  • Published specifications are compared with observed gateway and application traffic.
  • Deprecated versions and alternate hosts have an owner and retirement state.
  • GraphQL operations, batch endpoints, uploads, webhooks and callbacks are explicit.
  • Direct-service reachability is distinguished from gateway-mediated reachability.

The result should be a traceable inventory with provenance and confidence. Unknown ownership or authentication is a risk to resolve, not a reason to silently omit the route.

Build an identity, tenant and object matrix

For each object type, identify creators, owners, collaborators, reviewers, administrators and service identities. Add tenant relationships and lifecycle states such as invited, suspended, archived or transferred. These dimensions reveal BOLA, BFLA and IDOR paths that route-by-route testing misses.

Prepare same-role peer accounts and cross-tenant accounts with canary objects. Test allowed and denied pairs systematically. The matrix should distinguish read, write, delete, export, approve and bulk operations because a role may be authorised for one action but not another.

  • At least two identities exist for every role where horizontal access matters.
  • Cross-tenant tests use known objects and authoritative ownership state.
  • Object identifiers are varied in path, body, query, header and nested references.
  • Administrative and service identities are tested against least-privilege expectations.

Record the attempted identity-object-action pair and actual state. A 200 response is not necessarily a vulnerability, and a 403 response may still hide a side effect in a queue or downstream service.

Model authentication and token attack vectors

Document how credentials are issued, refreshed, revoked, exchanged and bound to clients. Test alternate authentication modes and recovery paths. A strong primary login does not protect an API if legacy keys, mobile refresh tokens, partner secrets or service-to-service exchanges grant broader authority.

Inspect token audience, issuer, scope, subject and tenant context at every hop. Confirm that gateways and services validate the properties they rely upon. Test whether identity context is replaced by headers that an upstream or direct caller can influence.

  • Expired, revoked, wrong-audience and cross-environment tokens fail consistently.
  • Refresh and recovery flows cannot upgrade role, tenant or client authority.
  • Service token exchange preserves the initiating user and permitted purpose where required.
  • Direct routes cannot inject trusted identity headers or skip gateway validation.

Capture the credential class and relevant claims without exposing reusable secrets. Connect acceptance to the component that validated—or failed to validate—the token.

Map sensitive business flows and state transitions

The highest-value API attacks often use valid functions in an invalid order, quantity, timing or identity. Map workflows such as onboarding, payment, refund, approval, invitation, entitlement, export and account recovery. Define the invariant and the authoritative state after each step.

Vary sequence, replay, concurrency, quantity and channel. Attempt steps from mobile and partner clients where the web interface hides them. Test whether asynchronous jobs recheck authority or trust the state captured when a request entered the queue.

  • Required prerequisites and approvals are enforced server-side at execution time.
  • Idempotency protects repeated financial or irreversible actions.
  • Bulk and export operations enforce the same object and tenant policies as single actions.
  • Queued work, retries and webhooks preserve current identity and state constraints.

Use synthetic records and stop at the minimum proof. Show both the request path and the authoritative business result so engineering can locate the failed invariant.

Include resource consumption and abuse economics

Rate limiting is not one number per IP address. Expensive searches, reports, exports, AI calls, file transformations and notification flows consume different resources and may be initiated through distributed identities. Model the protected resource and the business action, not only request velocity.

Test bounded bursts and account-level quotas under agreed limits. Examine pagination, filter complexity, GraphQL depth, upload sizes and repeated asynchronous jobs. Validate that rejection occurs before costly work and that one tenant cannot exhaust capacity assigned to others.

  • Limits account for user, tenant, credential, operation and protected resource.
  • Costly operations have budgets, cancellation and queue backpressure.
  • Errors do not reveal whether protected objects exist across tenants.
  • Monitoring connects abuse signals to identity and business impact.

A safe proof uses an agreed ceiling and observable resource metric. It should demonstrate the control gap without causing availability impact.

Test third-party and unsafe API consumption paths

Applications consume payment, identity, analytics, messaging and partner APIs. An attacker may influence a callback, redirect, URL, webhook or response that the application trusts. Map outbound destinations, signature verification, schema validation and failure handling.

Treat partner data as untrusted even when transport is authenticated. Verify that callbacks are bound to the correct transaction and tenant, that retries are idempotent, and that server-side fetches cannot reach internal metadata or administrative services.

  • Webhook signatures include freshness and are verified before side effects.
  • Callback state is bound to the initiating user, tenant and transaction.
  • Outbound destinations are allowlisted and protected against SSRF and redirect abuse.
  • External responses are schema-validated and cannot silently grant authority.

Trace the complete integration path and record which component accepted untrusted data. A partner brand or TLS connection does not prove the business message is authorised.

How WIMD would turn the map into a penetration test

WIMD would reconcile the published and observed API surface, then connect each critical operation to identities, tenants, objects and workflow state. We would not treat a route count as the scope denominator. The plan would identify security decisions and the test accounts, canary records and environments required to exercise them.

Testing would proceed through controlled hypotheses: a low-privilege actor attempts a prohibited object or function, a stale token crosses a service boundary, or an asynchronous consumer completes an action after authority changes. Evidence would include the full path and authoritative result.

The final report would group individual proofs by durable control point—shared policy middleware, token validation, tenant scoping, workflow service or integration boundary—so remediation fixes the pattern. Retesting would replay the original path and sample other consumers of the same control.

  1. Reconcile specifications, routes, runtime traffic, services and asynchronous integrations.
  2. Build role, tenant, object, action and lifecycle-state matrices for critical assets.
  3. Define prohibited outcomes and execute the smallest safe proof for each hypothesis.
  4. Trace decisions through gateway, service, data and worker layers with correlated evidence.
  5. Retest the root control across original and related paths after deployment.

Turn the map into a release and assurance decision

A defensible decision distinguishes observed low risk from untested risk. Review the identity pairs, tenant boundaries, workflows and integrations covered, then examine limitations. A clean scanner result cannot compensate for missing accounts or inaccessible business paths.

Maintain the map after the engagement. New API versions, clients, roles, tools and service routes should trigger targeted updates and testing. The map becomes a security engineering asset rather than a one-time spreadsheet.

  • Every critical API operation has an owner, identity model and security invariant.
  • Coverage records role, tenant, object, state and channel—not only route execution.
  • Asynchronous and third-party effects are verified against authoritative state.
  • Blocked and excluded paths remain visible in the residual-risk decision.
  • Root-cause remediation and related-path retesting are planned before closure.

Questions buyers and engineering teams ask

Is an OpenAPI specification enough to scope an API pentest?

It is an important input, but not the full scope. Reconcile it with gateways, application routes, client traffic, service inventories, GraphQL operations, webhooks and asynchronous consumers. Add identities, tenants, objects and workflows.

How many test accounts are required?

Use at least two identities for any role where horizontal access matters, plus cross-role and cross-tenant pairs that represent prohibited relationships. Lifecycle states and service identities may require additional accounts.

Should internal APIs be tested?

Test them when an attacker can reach them through a compromised workload, misrouted gateway, SSRF path, leaked credential or trusted integration. Scope and safe access should be agreed explicitly.

What is the most useful coverage metric?

Track completed security hypotheses across identity, tenant, object, action and state combinations. Endpoint execution counts can support operations, but they do not prove authorization or workflow depth.

Useful technical references

Make API scope reflect how the business actually works

Attackers do not respect the administrative boundary between a gateway, mobile client, worker and partner integration. A useful assessment follows the trust path and asks whether each component preserves the intended identity and state.

Build the map before testing, use it to record coverage, and keep it current after remediation. That makes API penetration testing more precise and gives engineering a durable model for future change.

Ask WIMD to map and test your API trust paths across gateways, identities, tenants, workflows, services and integrations.