Choose an API penetration testing company by asking it to model who can call which operation, on whose data, through which protocol and in which state. REST routes, GraphQL resolvers and microservices are implementation shapes; the security question is whether identity, authorization, business rules and trust survive every path from caller to effect.

Describe the API system, not only its endpoints

Start with callers and effects. Callers may include browser clients, mobile apps, partners, service accounts, scheduled jobs and internal services. Effects may include reading records, changing state, initiating payments, exporting data, issuing credentials or triggering asynchronous work. Between them may sit gateways, identity providers, resolvers, message brokers, caches and multiple services.

  • Interfaces: REST versions, GraphQL endpoints, webhooks, WebSockets, file or batch APIs and administrative routes.
  • Identities: end users, tenant administrators, platform staff, partners, machines and workload identities.
  • Objects: customer records, orders, documents, secrets, reports, jobs and cross-service references.
  • States: invited, active, suspended, deleted, approved, settled, expired and retried.
  • Trust: gateway assertions, propagated claims, internal headers, signed messages and service-to-service credentials.

Provide candidates with this model at an appropriate level of sensitivity. Ask each to return its coverage assumptions. A proposal priced only by endpoint count ignores that one GraphQL endpoint may expose hundreds of resolver decisions while ten REST endpoints may implement one simple read-only service.

Test whether the vendor understands authorization relationships

The most useful API selection conversation is about identity pairs and object relationships. Ask how the provider would test a user accessing a peer’s object, a tenant administrator crossing an organisation boundary, a lower role invoking an administrative function and a service account exceeding its delegated scope.

A mature answer requests two comparable users, roles and—where relevant—two tenants. It considers object identifiers in paths, bodies, filters, nested fields and indirect references. It also checks create, read, update, delete, export and action operations, because an API may protect viewing while allowing an unauthorised state change.

Use the OWASP API Security Top 10 to discuss common API risk classes, including object- and function-level authorization. Ask how the provider turns those classes into a system-specific matrix instead of a checkbox list.

Evaluate REST testing beyond route fuzzing

  • Schema mismatches, mass assignment and fields accepted but not exposed by the client.
  • Version drift, deprecated routes and inconsistent controls between public and internal variants.
  • Pagination, filtering and export functions that disclose more than a single-object request.
  • Idempotency, retries and race conditions around financial or state-changing operations.
  • Token audience, scope, expiry, revocation and privilege changes during an active session.

Ask how the team combines specification coverage with real client traffic and architecture. Neither the specification nor the client should be assumed complete.

Evaluate GraphQL-specific reasoning

GraphQL security depth lies in resolvers, fields and relationships rather than the single transport endpoint. The provider should discuss field-level authorization, nested traversal, mutation permissions, aliases and batching, introspection decisions, query complexity, subscription channels, tenant-aware caching and federation trust.

Ask for a sample coverage representation. A useful approach maps roles to query fields, mutations and sensitive object relationships, then tests both direct and nested access. The team should also understand that disabling introspection is not a replacement for authorization and that denial-of-service validation requires bounded, agreed techniques.

Evaluate microservice and gateway trust analysis

External behaviour can appear correct while internal services trust spoofable headers, over-broad workload identities or caller-controlled tenant context. Ask how far the engagement follows a request beyond the gateway and how the provider handles services not directly reachable from the internet.

  • Can a service be reached through an alternate route that bypasses gateway policy?
  • Does downstream authorization rely on an identity or tenant header that another component can influence?
  • Are service credentials scoped to the operations and data the workload needs?
  • Can a low-trust service invoke a high-impact internal function?
  • Do queues, callbacks and jobs revalidate authority when work is executed later?

The right scope may combine external API testing with targeted internal or source-assisted validation. A trustworthy provider states what its access model can and cannot prove.

Ask how undocumented and shadow APIs are found

Specifications age quickly. A provider should reconcile OpenAPI or GraphQL definitions with client bundles, mobile traffic, gateway inventories, DNS and certificates, observed requests, logs or developer input. Discovery must remain authorised and bounded; finding a hostname does not automatically place it in scope.

Examine business-logic testing

API abuse often uses valid requests in an invalid sequence or context. Ask the proposed tester to reason about one critical workflow—for example account invitation, order approval, payment refund or report export. Listen for invariants, state transitions and competing identities rather than a list of payloads.

  1. State the rule that must always hold, such as “a refund cannot exceed the captured amount.”
  2. Identify actors, objects, states and channels that participate in the rule.
  3. Vary sequence, identity, quantity, timing, retry and transport while observing the authoritative final state.
  4. Test whether asynchronous workers and callbacks repeat the same authorization and integrity checks.
  5. Bound proof to safe values and agreed test data, then preserve reproducible evidence.

Review automation and safety together

APIs make high request volumes easy, which means testing discipline matters. Ask how concurrency, rate, mutation and expensive GraphQL queries are controlled. The rules of engagement should cover source addresses, test accounts and data, request markers, prohibited operations, third-party endpoints, stop conditions and operational escalation.

A provider should not equate aggressive traffic with depth. Controlled automation can enumerate schemas, compare responses and repeat role matrices; human reasoning should decide what to vary, how to interpret differences and when proof is sufficient.

Inspect API finding evidence

A developer-ready API finding should show the caller identity and privileges, relevant request, important response, object ownership, expected rule, observed violation, impact and safe reproduction steps. It should explain whether the issue is at the gateway, service, resolver, shared middleware or business layer when evidence supports that conclusion.

  • Requests and responses are redacted without removing the details needed to reproduce.
  • Tokens and customer data are minimised, encrypted and retained only as agreed.
  • Severity reflects proven reach and business effect, not only a taxonomy label.
  • Related symptoms are connected to a root cause without concealing distinct affected paths.
  • Retest criteria state both the original exploit and meaningful bypass variants.

Score the shortlist on API-specific evidence

  • Surface discovery across documented, observed, versioned and internal interfaces.
  • Authorization depth across peer users, roles, tenants, objects, functions and lifecycle states.
  • Protocol knowledge for REST, GraphQL and any real-time or asynchronous channels in scope.
  • Ability to reason about workflows, retries, races, callbacks and authoritative state.
  • Understanding of gateway, resolver, service and workload-identity trust boundaries.
  • Safe automation, coverage transparency, evidence quality and independent retesting.

Red flags in API vendor discovery

  • The vendor asks only for an endpoint list and a bearer token.
  • Authorization coverage is promised with one user account or one tenant.
  • GraphQL testing is described only as introspection and query-depth scanning.
  • Internal services are declared secure merely because they are behind a gateway.
  • The proposal promises all endpoints tested but provides no model for sampling fields, objects or states.
  • The report sample omits identity context, object ownership or the authoritative final effect.

Make a decision that survives technical scrutiny

Select the API penetration testing company that can connect callers to effects across protocols and services, demonstrate a rigorous authorization and business-logic method, operate at safe volume and provide transparent coverage. Document which interfaces and trust boundaries the approval covers; capability for a public REST API does not automatically prove suitability for a federated GraphQL or internal microservice environment.

WIMD approaches API testing as an identity, object, action and state problem. Specifications and automation provide breadth; manual analysis targets ownership, workflow and trust; safe evidence proves impact; and retesting checks the original path plus relevant variants. That delivery model is available for technical review before an engagement begins.