Evaluate an API penetration-testing vendor by asking it to reason through identity, object, function and service trust in a representative architecture. A provider that recognises the terms BOLA, BFLA, OAuth, JWT and microservices may still lack the ability to test how those controls interact in your deployed system.

Give every vendor the same API scenario

Describe a SaaS platform with two tenants, member and administrator roles, REST APIs, a GraphQL reporting endpoint, an OAuth-based partner integration, a gateway, several internal services and an asynchronous export worker. Include one privileged support path and a token refresh flow.

Ask what information and access the team requires. Strong answers request comparable users, tenants, object ownership, role definitions, token and client types, service maps, API specifications, safe test data and logging contacts. Weak answers ask only for a base URL and bearer token.

  • At least two peer users and two tenants for relationship tests.
  • Representative privileged, support, partner and machine identities.
  • Objects in different ownership and lifecycle states.
  • Documented and observed API paths, including asynchronous effects.

Validate BOLA understanding through an object matrix

Broken object-level authorization occurs when a caller can act on an object without the required relationship. Ask the vendor to build a matrix of actors, object owners, tenants, states and operations. The answer should go beyond changing an ID in a URL.

  • Peer user accessing another peer’s object within the same tenant.
  • A user in one tenant accessing an object in another tenant.
  • A former owner, removed member or expired invitation retaining access.
  • Indirect disclosure through search, count, export, cache or notification.

Validate BFLA through functions and workflow state

Broken function-level authorization is more than calling an endpoint labelled admin. Ask how the provider discovers privileged operations and tests them with lower roles, alternate methods, versions and internal routes. The method should include functions hidden from the user interface.

Then add state. A user may be allowed to invoke a function only after approval or only for a certain account. The vendor should test whether sequence, stale roles or alternate channels bypass that contextual authority.

  • Administrative functions invoked by a member or partner identity.
  • Method, version or route variants with inconsistent middleware.
  • Bulk and export functions that enforce different checks from single-object routes.
  • Privileged actions reached through workers, callbacks or internal services.

Ask the vendor to draw the actors and trust boundaries in the OAuth flow: resource owner, client, authorization server and resource server, plus redirect endpoints and any broker. It should distinguish client type, grant, redirect validation, state binding, PKCE, consent, audience and scope.

The evaluation should cover account linking, multiple identity providers, login CSRF, redirect manipulation, code interception, token substitution and privilege retained after consent or account changes where applicable. The provider must adapt tests to the implemented flow rather than demand obsolete grants.

  • Redirect URI and client binding are enforced consistently.
  • Authorisation responses are tied to the initiating browser or app transaction.
  • Scopes and audiences are checked by the correct resource service.
  • Revocation, logout and identity changes affect active access as designed.

Test JWT validation and lifecycle

Decoding a JWT is not a security assessment. Ask how the vendor validates signature and algorithm handling, issuer, audience, expiry, not-before time, key selection and claims used for authorization. It should examine where tokens are created, exchanged, refreshed and consumed.

Claims may become unsafe when a gateway validates the signature but downstream services trust caller-controlled headers or fail to enforce audience and tenant context. The tester should trace effective identity through the service path and compare behaviour during role changes and key rotation.

  • Algorithm and key selection cannot be influenced into unsafe verification.
  • Issuer and audience match the receiving service and environment.
  • Role, tenant and subject claims cannot be replayed beyond intended context.
  • Refresh, rotation, revocation and session termination have testable outcomes.

Probe gateway-to-microservice trust

Ask what the public gateway proves and what each service assumes. A vendor with microservice depth looks for alternate routes, trusted headers, over-broad service credentials, missing downstream authorization and confused-deputy paths. “Internal” is a network description, not an authorization model.

Give the candidate one scenario where a low-trust service calls a high-impact operation. Ask how it would obtain a realistic testing position without unsafe access. The answer may combine external, internal, source-assisted and log-supported techniques, with limitations stated clearly.

  • Direct service reachability that bypasses gateway policy.
  • Identity or tenant headers accepted without protected provenance.
  • Workload identities allowed to call unrelated functions or tenants.
  • Service-to-service calls that propagate user authority inaccurately.

Include GraphQL resolvers and field authorization

One GraphQL endpoint can contain many authorization decisions. Ask how the vendor maps roles to queries, mutations, fields and object relationships. It should test direct and nested access, aliases, fragments, batching and resolver differences rather than reporting that introspection is enabled.

  • Sensitive fields reached through nested relationships.
  • Mutations or resolver functions exposed to the wrong role.
  • Tenant or identity context lost across federated services.
  • Cached results reused across users or organisations.

Examine asynchronous and event-driven authorization

Exports, webhooks, queues and workers often complete after the initiating request. Ask whether authority is captured, revalidated or delegated, and how the final artefact is protected. An accepted request is not proof the later effect is safe.

The vendor should test ownership of job identifiers and output locations, callback authenticity, event replay, ordering, retries and stale privileges. Evidence must include the authoritative downstream result, not only the initial HTTP response.

  • Another user cannot fetch or infer a queued job or export.
  • Workers do not trust caller-supplied tenant or privilege context blindly.
  • Duplicate events and retries preserve idempotent business effects.
  • Callbacks are authenticated, scoped and resistant to replay.

Inspect the evidence the vendor would produce

Provide a synthetic BOLA example and ask how it appears in the report. The finding should name both identities and object ownership, show the allowed control case and prohibited access, preserve relevant requests and prove the final effect. A response difference without ownership context is weak evidence.

Ask how related endpoints are sampled and how root cause is reported. The vendor should avoid both extremes: dozens of duplicate findings with no pattern, or one broad finding that hides which services and operations were actually confirmed.

  • Evidence includes caller, token context, object relationship and operation.
  • Impact is demonstrated without unnecessary production data exposure.
  • Severity reflects reach and prerequisites, not the acronym alone.
  • Retest criteria cover the shared enforcement pattern and relevant variants.

Score capability, not vocabulary

Create a scoring sheet before the call. Weight authorization matrices, token lifecycle, service trust, GraphQL and asynchronous testing according to your architecture. Give credit for precise prerequisites, safe proof and honest limitations. Deduct for rote taxonomy recitation.

  1. Score the scenario response independently across evaluators.
  2. Request one sanitised API finding and one coverage artefact.
  3. Resolve gaps through equal written questions to all candidates.
  4. Advance only vendors whose demonstrated method fits the real architecture.

Use the official OWASP API Security Top 10 2023 as a risk vocabulary. For token design and validation, refer to the OAuth 2.0 Security Best Current Practice and JSON Web Token Best Current Practices. Confirm the implemented protocol and architecture before selecting tests.

Make API capability observable before appointment

A credible API vendor should improve your model of callers, tokens, objects, functions and services during evaluation. Its approach should remain useful when the API description is incomplete, the system is distributed and business state matters more than isolated endpoints.

WIMD validates API capability through role-and-tenant matrices, token-lifecycle analysis, REST and GraphQL coverage, service-trust hypotheses and evidence of asynchronous effects. The same method drives reporting and retesting so the buyer can trace assurance from scope to closure.