GraphQL concentrates many object and function boundaries behind a small number of HTTP endpoints. A scanner that reports introspection, depth or version information may miss the harder risks: field-level authorization, nested object access, resolver side effects, batching, federation and cross-tenant caching.

Vendor selection should therefore use a GraphQL-specific working session. Give candidates a small schema and role model, then ask them to build a coverage and abuse plan. The objective is to see whether the named tester understands how a graph becomes executable business authority.

Confirm the actual GraphQL architecture

Provide endpoint locations, client types, authentication, schema ownership, gateway or federation model, subscriptions, file handling, persisted queries and environments. Ask the candidate to identify which facts change the test plan.

A credible tester distinguishes a monolithic schema from a federated graph, public clients from server-to-server consumers and queries from mutations or subscriptions. It asks where identity, tenant context and policy are injected and whether downstream services repeat authorization.

  • Gateways, subgraphs and direct service routes.
  • HTTP, WebSocket and other transports in scope.
  • Persisted or allowlisted operation controls.
  • Role, tenant and object ownership model.

Evaluate schema discovery without overvaluing introspection

Ask how the tester builds an operation inventory when introspection is enabled, disabled or filtered. Strong answers combine client traffic, documentation, error behaviour, static artefacts and authorised schema access.

Introspection is not automatically a high-severity vulnerability, and disabling it is not complete protection. The evaluation should focus on reachable fields and functions, exposed information and how an attacker can use the graph under the actual access model.

  • Queries, mutations and subscriptions are inventoried separately.
  • Arguments, custom scalars, directives and deprecated operations are considered.
  • Hidden or role-specific fields are tested with multiple identities.
  • Discovery limitations are recorded as coverage constraints.

Test object and field authorization through relationships

Give two users and objects with distinct ownership. Ask how the vendor will compare direct lookup, nested traversal, aliases, fragments and list results. Field authorization can fail even when the top-level object check succeeds.

The tester should trace each sensitive value to the resolver that returns it and identify where owner, role and tenant decisions occur. A generic response difference without the caller-to-object relationship is weak proof.

  • Direct and nested access enforce the same ownership rule.
  • Sensitive fields are protected independently where required.
  • Connections, nodes and pagination do not leak other tenants.
  • Global or opaque identifiers cannot bypass contextual checks.

Validate mutation and business-function authority

Mutations may group create, update, approve, export and administrative effects. Ask the candidate to test each function with lower roles, alternate object IDs, omitted fields, aliases and unexpected sequence.

Inputs can reach multiple resolvers or asynchronous jobs. A capable vendor follows the mutation to the final state, rather than treating a successful GraphQL response as the entire effect.

  • Lower roles cannot invoke privileged mutations.
  • Writable fields cannot set server-controlled ownership or status.
  • Partial resolver failure does not leave an unsafe business state.
  • Repeated mutations are idempotent where the workflow requires it.

Probe aliases, batching and multi-operation requests

GraphQL allows many logical actions in one request. Ask how rate limits, authorization, logging and transaction handling behave with aliases, arrays or batched transport requests. The vendor must propose bounded tests and stop conditions.

Batching can amplify weak controls or mix identities and objects in confusing evidence. The report should identify which operation caused each effect and whether limits apply per HTTP request, operation, resolver or account.

  • Aliases cannot evade per-operation or per-object checks.
  • Batch processing preserves identity and tenant context.
  • One failed operation cannot expose another operation’s result.
  • Audit logs retain usable operation-level attribution.

Assess query cost and denial-of-service controls

Depth alone is not a sufficient model of cost. Ask how the tester evaluates breadth, list cardinality, fragments, aliases, recursive relationships, resolver fan-out and expensive downstream calls. It should work with owners on safe ceilings.

Strong candidates distinguish application resource exhaustion from stress testing. They use controlled increments, monitoring and representative queries, then explain whether controls constrain cost before scarce work occurs.

  • Limits consider depth, breadth, cardinality and resolver cost.
  • Pagination has enforced maximums and stable authorization.
  • Timeouts and cancellation propagate to downstream work.
  • Anonymous and authenticated budgets reflect business need.

Include subscriptions and real-time channels

If subscriptions are used, ask how authentication is established, refreshed and revoked across a long-lived connection. The provider should test topic authorization, tenant isolation, reconnection and event filtering.

An initial authorized handshake does not prove every later subscription or event is permitted. Evidence should show the subscribing identity, selected topic, event source and unauthorized data or action.

  • Connection and subscription authorization are both evaluated.
  • Role or account changes affect active sessions as designed.
  • Topic identifiers cannot cross user or tenant boundaries.
  • Error and reconnect paths do not disclose stale events.

Examine federation and downstream trust

Federated graphs distribute resolution across services. Ask how the tester maps entity identifiers, gateway-injected headers, service accounts, direct subgraph exposure and policy ownership.

The strongest answer tests whether subgraphs trust unprotected identity or tenant context, whether internal routes bypass gateway policy and whether entity resolution exposes fields not intended in the composed graph.

  • Direct subgraph paths do not bypass required controls.
  • Trusted headers have protected provenance.
  • Entity resolvers enforce ownership and tenant context.
  • Caching does not reuse responses across identities.

Ask for GraphQL-native evidence

Review a sanitised finding. It should include the complete operation, variables, identity, relevant schema path, control case, prohibited result and final effect. A screenshot of a GraphQL client or a claim that introspection worked is not enough.

Ask the candidate to explain root cause at the resolver, gateway or downstream-policy layer and to propose a repair that fits the architecture. Generic advice to disable introspection should not substitute for authorization remediation.

  • Operation and variables are reproducible and safely redacted.
  • Aliases or batching are expanded enough to show the failing unit.
  • Severity reflects data or function impact and prerequisites.
  • Retest covers direct, nested and alternate-operation variants.

Run a scored technical exercise

Provide a miniature schema containing users, organisations, invoices, an export mutation and a subscription. Give a member and administrator token. Ask the named lead tester to build an authorization matrix, three abuse hypotheses and a safe cost test.

Score the reasoning, not presentation polish. A good candidate asks about resolver ownership, object relationships, tenant context, downstream effects and monitoring.

  1. Score schema and operation inventory.
  2. Score resolver-level identity and object reasoning.
  3. Score batching, cost and federation coverage.
  4. Score evidence, safety and retestability.

Make coverage an engagement deliverable

Require a matrix of operation, field or resolver family, identity, tenant, test status and constraint. This prevents a single endpoint from creating an illusion of complete coverage.

Agree how schema change during the engagement is detected and handled. Persisted operations, generated clients and federated composition may change while testing is underway, so the baseline and cut-off must be explicit.

Use the official OWASP GraphQL Cheat Sheet for defensive themes and the OWASP Web Security Testing Guide for testing method. Map API authorization risks with the OWASP API Security Top 10 2023. These are inputs to an architecture-specific test, not substitutes for a coverage model.

Choose a vendor that sees the executable graph

GraphQL capability is visible in how a tester connects a client operation to resolver authority, downstream trust and business impact. Tool output is useful only when it supports that reasoning.

WIMD evaluates GraphQL providers using role-and-tenant matrices, schema and operation coverage, bounded cost tests, federation hypotheses, GraphQL-native evidence and explicit retest variants.