TL;DR:
REST security testing is built around a set of structural assumptions: fixed endpoints, predictable HTTP methods, consistent response shapes. GraphQL violates most of them. This post explains which specific assumptions break, and why that gap matters for teams running security tests against APIs that include GraphQL endpoints.
The problem this post is addressing
Most security testing tools and practices were designed for REST APIs. The mental model is well-established: each endpoint exposes a specific resource, the HTTP verb signals the operation, and the server enforces access control per route. You test each endpoint, check what authentication is required, verify that the method restrictions hold, and confirm the response does not leak unintended data.
GraphQL does not work that way. And when teams apply REST-oriented testing logic to a GraphQL endpoint, the test passes on conditions that would never survive a real attacker.
What REST security testing actually assumes
Before examining where GraphQL breaks the model, it helps to be explicit about what REST-based security testing depends on.
REST assumes that the server determines what is returned. A client requests a resource. The server decides what fields to send back. Access control sits at the route level: can this user access /users/123? If yes, the server returns the predefined response shape.
REST assumes that each operation has a corresponding, testable endpoint. You can enumerate a REST API's surface by mapping its routes. Scanners can crawl, fuzz individual endpoints, and verify access control by testing each route against different authentication states.
REST assumes that HTTP methods carry semantic meaning that the server enforces. GET requests read. POST requests write. A DELETE on a resource a user cannot access should return a 403.
These assumptions form the basis of how automated and manual testing approaches are typically structured. They hold reasonably well for REST. For GraphQL, they do not hold at all.
The structural differences that break those assumptions
A single endpoint handles everything.
A GraphQL API typically exposes one endpoint, almost always /graphql, that processes every operation the client sends. The operation itself is defined in the request body, not the URL path or HTTP method. A security scanner that discovers the /graphql endpoint has not discovered the API's attack surface. It has discovered the door. What is behind that door is determined entirely by the query language the client uses, and that query language is flexible by design.
This means route-level access control testing, the foundation of REST security scanning, does not apply to GraphQL in the same way. There is only one route.
The client specifies what data it wants, field by field.
According to the GraphQL specification, the client constructs a query that names exactly which fields it wants returned. The server resolves those fields from its data layer and sends back precisely what was requested.
This design creates an authorization problem that REST APIs rarely encounter in the same form. In a REST API, the server controls the response shape. In a GraphQL API, the server must evaluate whether the requesting user is authorized to receive each individual field they asked for. That authorization check has to happen at the resolver level, the function that fetches data for each field. If resolver-level authorization is inconsistent or missing, a user can request fields they should not have access to by simply including them in the query. The HTTP response returns 200 regardless.
This is a common finding in GraphQL implementations. Field-level authorization is conceptually straightforward but operationally easy to miss during development, particularly when resolver logic is added incrementally by different teams. A scanner that checks status codes and endpoint responses will not catch it.
Introspection exposes the schema on request.
By default, GraphQL APIs allow any client to send an introspection query and receive a complete description of the API's types, fields, queries, and mutations. This is useful for development tooling and documentation generation. From a security testing perspective, it is also a complete map of the API's capabilities.
An attacker who can run an introspection query against an unprotected GraphQL endpoint does not need to guess what the API can do. The API will tell them. This is documented in the OWASP API Security Top 10 as a configuration risk, but the more significant problem is what introspection enables: targeted queries against fields and types that an attacker now knows exist. A scanner that does not understand how to interpret introspection output will not know what to test.
Batching and nested queries change the cost of an attack.
REST endpoints expose one operation per request. GraphQL allows a client to batch multiple operations into a single request, or to nest object relationships several levels deep in a single query. Both capabilities have legitimate uses in production APIs. Both also change the economics of certain attack classes.
An attacker looking to cause resource exhaustion does not need to send thousands of individual requests against separate endpoints. A single deeply nested GraphQL query can instruct the server to resolve a chain of related objects until the server runs out of time, memory, or database connections. Many GraphQL implementations ship without query depth or complexity limits configured. The default behaviour is permissive. Confirming that a REST API handles a high volume of requests without degrading performance is a different test from confirming that a GraphQL API has bounded query complexity. The same testing assumption does not cover both.
What this means in practice for security teams
Security testing against a GraphQL endpoint requires a different starting point than REST testing. The questions change.
For REST, the primary question is: can this authenticated user access this endpoint and this HTTP method? For GraphQL, the primary questions are: can this authenticated user access each field they can request through a valid query? Does the API expose its schema through introspection without requiring authentication? Are there bounds on query depth and complexity that would prevent resource exhaustion through crafted queries? Can multiple operations be batched in ways that bypass rate limiting applied at the request level?
None of those questions map cleanly onto REST-oriented testing logic. Teams running scanners against GraphQL endpoints need to confirm that their tooling understands GraphQL query construction, can exercise resolver-level authorization checks, and can interpret introspection results to expand the test surface rather than just note that introspection is enabled.
Authenticated GraphQL testing adds another layer. A scanner that cannot operate within an active session cannot test whether resolver-level authorization holds for different user roles and privilege levels. Most GraphQL authorization vulnerabilities appear in authenticated contexts, where a regular user can access another user's data or escalate their access by requesting fields their resolver should have rejected. That class of finding requires the scanner to operate as an authenticated user, not just as an unauthenticated probe. ZeroThreat's authenticated API scanning handles this by operating within recorded session state, which means the authorization checks that only appear after login are actually tested rather than skipped.
The shift from REST to GraphQL is not just an architectural preference. It is a change in the security assumptions the API's design depends on, and it requires a corresponding change in how security testing is structured. Teams that recognize that gap early tend to find the real vulnerabilities before someone who does not have their best interests in mind finds them first.