Cybersecurity glossary
What is GraphQL?
Learn what GraphQL is, how clients query a typed schema over HTTP, how it differs from REST, and which security controls stop abuse like over-fetching and resolver attacks.
Definition
GraphQL is a query language and runtime for APIs that lets clients request exactly the fields they need from a typed schema, typically over HTTP, with a single endpoint resolving nested data through server-defined resolvers.
Why GraphQL matters
Mobile and web clients rarely need an entire REST resource representation. They need a few fields from a user, a nested list of orders, and maybe a related inventory flag—without five round trips.
GraphQL lets clients declare that shape against a server-owned schema. Done well, it reduces chatter and keeps UI teams moving. Done poorly, it becomes an unbounded query engine pointed at your databases.
How GraphQL works
Publish a typed schema
Types, fields, queries, mutations, and subscriptions define the contract clients may use.
Client sends an operation
A query or mutation document lists requested fields, often as a POST to a single HTTP endpoint.
Server parses and validates
The document must match the schema; unknown fields and type errors fail before resolvers run.
Resolvers fetch nested data
Each field can call databases, caches, or downstream services to build the response tree.
Authorization applies per field or type
Effective designs check permissions where data is loaded—not only at the HTTP door.
A shaped JSON response returns
Clients receive exactly the requested structure (plus errors) in one payload.
GraphQL vs REST
| Topic | GraphQL | Typical REST |
|---|---|---|
| Endpoints | Usually one URL for many operations | Many resource URLs and methods |
| Data shape | Client selects fields | Server defines representations |
| Over/under-fetching | Reduced when schema is well designed | Common without BFF endpoints |
| Caching | Harder at HTTP layer; needs app strategies | Natural fit for GET + cache headers |
| Abuse surface | Deep/nested queries and batching | Many routes; still needs authz and quotas |
Strengths and trade-offs
Flexible clients
Web and mobile can evolve field needs without waiting for a new REST resource version each time.
Strong schema documentation
Introspection and tooling make contracts discoverable for legitimate developers.
Resolver complexity
N+1 query patterns and nested fan-out can crush databases without dataloaders and budgets.
Operational caching
Because queries vary, CDN caching is less straightforward than for stable REST GETs.
GraphQL security essentials
Authorize in resolvers
Every sensitive field and object ID needs a permission check; nested queries bypass shallow gateway auth.
Limit depth and complexity
Cap nesting depth, calculated cost, and aliases/batching to stop resource exhaustion.
Restrict introspection in production
Disable or tightly control schema discovery on public endpoints.
Timeout and paginate lists
Unbounded connections are denial-of-service invitations; force pagination arguments.
Separate mutations carefully
Treat state changes like privileged REST writes with CSRF/SameSite strategy if cookie auth is used.
Monitor operation names and costs
Alert on sudden spikes in expensive operations, not only HTTP 5xx rates.
Practical checklist
- Enforce authentication before executing any production GraphQL operation.
- Implement object-level and field-level authorization tests (including nested IDOR cases).
- Set max depth, complexity/cost analysis, and query timeouts.
- Require pagination on list fields; reject huge `first`/`last` values.
- Disable unused introspection and GraphiQL in production.
- Use dataloaders or equivalent batching to prevent N+1 database load.
- Apply rate limits that account for query cost, not only request count.
- Log operation name, user, cost estimate, and outcome for abuse investigations.
The practical takeaway
GraphQL gives clients a precise way to query a typed API schema, which can simplify product development and cut over-fetching. The same flexibility can amplify authorization mistakes and expensive resolver graphs.
Adopt GraphQL with explicit budgets: authenticate, authorize deeply, cap complexity, paginate relentlessly, and observe operation cost. A single endpoint is convenient—only if it is not an unbounded query engine.
Related security terms
Representational State Transfer (REST)
The resource-oriented API style most often compared with GraphQL.
API Abuse
Costly or malicious GraphQL queries are a common abuse pattern.
Rate Limiting
Necessary but incomplete; GraphQL often needs complexity-aware limits too.
Insecure Direct Object Reference (IDOR)
Broken object authz in resolvers leads to classic IDOR via nested queries.
Broken Authentication
Auth gaps on GraphQL endpoints expose the entire schema surface.
Frequently asked questions
What is GraphQL in simple terms?
It is an API style where the client asks for a shaped bundle of data in one request—like ordering exactly the fields you need—instead of calling many fixed REST endpoints.
Does GraphQL replace REST?
Sometimes for product APIs, but many organizations run both. REST remains common for simple resources, webhooks, and file uploads.
Is GraphQL only for graphs/databases?
No. The “graph” is the schema of related types. Resolvers can read SQL, documents, caches, or other HTTP services.
What is introspection?
A built-in way for clients to ask the server what types and fields exist. Useful in development; often restricted in production.
Why is GraphQL hard to rate-limit?
One HTTP request can trigger hundreds of resolver calls. Limits based only on request count miss expensive nested queries.
Are mutations different from queries?
Yes. Queries read data; mutations change state. Both need authorization, and mutations especially need idempotency and audit trails.
Can GraphQL run over WebSockets?
Yes. Subscriptions commonly use WebSockets or SSE-like channels for push updates, with their own auth requirements.
References
Explore authoritative guidance and frameworks related to graphql.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.