An API scope cannot be reduced to a base URL and endpoint total. The tester needs to know operations, callers, tokens, objects, tenants, workflows and service paths that make each request authoritative.

A strong checklist creates a shared inventory for quotation, testing and closure. It also records uncertainty: undocumented routes, evolving schemas and inaccessible internal services should become visible limitations or approved changes.

Build the scope with API owners, client developers, identity teams and operations rather than relying on a single specification export. Each group sees a different part of the effective interface, and their reconciliation often reveals deprecated hosts, privileged service routes or workflow effects that a document alone does not show.

List API hosts, environments and versions

Record public, partner, mobile, administrative and internal hosts with ownership and network path. Distinguish production, staging and mock services.

Include active and deprecated versions and define whether direct service hosts are authorised. A gateway URL alone may hide materially different policy paths.

Assign an owner to every host and record how it was discovered. Orphaned and duplicate gateways should remain visible until architecture owners confirm whether they are retired, redirected or independently reachable.

  • Canonical base URLs.
  • Environment and region.
  • Version and deprecation status.
  • Gateway, service and alternate routes.

Inventory unique operations

Count method-and-path combinations, GraphQL operations, RPC methods and message actions rather than raw paths. Include content types, bulk variants and administrative functions.

Validate documentation against observed clients and logs where available. State sampling for repeated operations and keep undocumented discoveries in change control.

  • HTTP method and normalized path.
  • Version and media type.
  • Bulk, import, export and callback.
  • Deprecated and hidden operations.

Define callers, roles and tenants

List human roles, clients, partners, service accounts and anonymous access. Map organisations, tenants and delegation.

Provide enough identities to compare owner, peer, outsider and privileged behaviour. One administrator token cannot support meaningful authorization testing.

  • User and platform roles.
  • Tenant or organisation matrix.
  • Workload and integration identities.
  • Pending, disabled and revoked states.

Map objects and functions

Identify sensitive object families and high-impact operations. Record ownership, sharing, parent-child and transfer relationships.

Separate object-level access from function-level privilege. A user might read its invoice but must not approve refunds or invoke platform administration.

  • Object identifiers and ownership.
  • Read, modify, delete and share.
  • Privileged business functions.
  • Nested and indirectly related data.

Describe authentication and token flows

Document OAuth or OIDC actors, grants, redirects, scopes, audiences and clients; JWT issuers and keys; API keys, signatures or mutual TLS.

Include issuance, exchange, refresh, rotation, revocation, logout and role change. Static tokens omit important attack paths and can distort scope.

  • Authorization and resource servers.
  • Client types and grants.
  • Scope and audience model.
  • Key and session lifecycle.

Map critical multi-call workflows

List onboarding, approval, payment, payout, export and other stateful journeys. Identify sequence, roles, idempotency and final authoritative records.

Include replay, concurrency, cancellation and administrative intervention where business harm can occur. Operation inventory alone cannot describe these tests.

  • Expected state transitions.
  • Retry and idempotency.
  • Concurrent or duplicate actions.
  • Final ledger, job or data effect.

Include GraphQL and alternate protocols

Record schemas, queries, mutations, fields, subscriptions and federation. For gRPC or messaging, provide contracts, clients and reachable transports.

Do not count one GraphQL endpoint as one test unit. Scope resolver families, identities and cost controls explicitly.

  • Schema and operation sources.
  • Resolver or service ownership.
  • Streaming and subscription identity.
  • Federated or binary protocol boundaries.

Trace gateways and microservices

Document gateway policy, trusted headers, workload identity, service mesh and direct routes. State whether internal testing is included and how access will be provided.

Identify which service makes authorization decisions and how user and tenant context propagate. Edge-only testing should be labelled as such.

  • Gateway enforcement and transformation.
  • Direct service reachability.
  • Service-account privileges.
  • Identity and tenant propagation.

Include asynchronous integrations

Map webhooks, queues, workers, callbacks, exports and scheduled jobs. Record authentication, event identifiers and output storage.

Scope replay, ordering, duplicate delivery, job ownership and stale privilege. The initiating response is not the complete security outcome.

  • Inbound and outbound webhooks.
  • Queue or event topics.
  • Job status and output access.
  • Retry and dead-letter behaviour.

Provide contracts, data and readiness

Supply OpenAPI, schemas, collections, example payloads and error models with known gaps. Create representative accounts, objects and workflow data.

Test access, allowlisting and token issuance before kickoff. Define the process when documentation is stale or data cannot be restored.

Provide both permitted and prohibited examples for high-risk authorization decisions. A tester needs known owner, peer and cross-tenant objects to distinguish secure denial from missing data, an invalid identifier or an unrelated processing error.

  • Machine-readable contracts.
  • Client and sample requests.
  • Seeded identities and objects.
  • Technical owner and blocker route.

Set safe operating limits

Define rate, concurrency, payload and resource ceilings, excluded destructive operations and third-party costs. Use designated data and financial values.

Production testing needs monitoring, critical escalation and stop authority. Resource-exhaustion testing must have a separate approved method.

  • Rate and concurrency ceilings.
  • Financial and notification limits.
  • Prohibited downstream effects.
  • Emergency stop and reconciliation.

Require coverage and closure evidence

The final matrix should map operations or families, identities, objects and status. Findings preserve caller, token context, control comparison and final effect.

Define report formats, review and retest cycles. Closure should cover the repaired enforcement pattern and representative variants, not only replay one request.

Ask the provider to identify which conclusions depend on shared gateway or middleware enforcement and which were verified directly in downstream services. This distinction makes systemic assurance and residual blind spots visible. Record the evidence source for each conclusion.

  1. Reconcile inventory with observed traffic.
  2. Approve role-object-workflow matrices.
  3. Record sampling and constraints.
  4. Accept coverage and retest evidence.

Use the OWASP API Security Top 10 2023, the OWASP Web Security Testing Guide and NIST SP 800-115 as authoritative inputs to architecture-specific API planning.

Scope the authority behind every operation

An endpoint list locates requests; a defensible API scope explains callers, tokens, objects, state and downstream trust.

WIMD builds operation, identity and workflow matrices that support comparable quotations, safe execution and reproducible evidence-based closure.