GraphQL pentest guide for SaaS products

GraphQL changes API testing because many actions flow through one endpoint. That endpoint can hide a large schema, many roles, nested objects, mutations, and fields that were never meant to be exposed to every user. A pentest has to understand the graph, not just the URL.

Start with schema visibility. Introspection may be intentionally enabled or disabled, but the tester still needs a way to understand queries, mutations, object types, and expected authorization boundaries. If introspection is enabled in production, confirm whether it exposes sensitive internal types or admin workflows.

Authorization is the main event. Test field-level authorization, object-level authorization, nested relationship access, mutations across tenants, organization switching, and role transitions. A user who cannot view a billing object through the UI should not be able to fetch it through a nested GraphQL query.

Batching and aliasing deserve focused checks. Attackers can pack repeated operations into one request, brute force IDs, bypass rate limits, or hide expensive operations behind aliases. Rate limiting should understand GraphQL operation cost, not just HTTP request count.

Depth and complexity limits matter for availability and data exposure. Deep nested queries can cause performance issues, reveal relationship maps, or accidentally return fields that UI paths never request. Test practical limits and how errors are returned.

Evidence should include the query, variables, role, expected behavior, actual response, and business impact. GraphQL findings can be hard to reproduce if the report only says field-level authorization was missing.

DeepScan API workflows include GraphQL-specific exploration and exploit validation so findings are not lost inside a generic API report.