Graphql Security Basics: Introspection, Depth Limiting, And Persisted Queries

GraphQL gives you something REST never really did: the ability for clients to describe exactly what they want. Graphql Security Basics: Introspection, Depth Limiting, And Persisted Queries

That flexibility is why teams adopt it and also why GraphQL needs more deliberate security thinking than “we put it behind auth, we’re good.”

With REST, the server controls the shape of the response. Each endpoint is a pre-baked contract. If it’s slow, you profile that endpoint and fix it.

With GraphQL, the server exposes a graph. The client controls how that graph is traversed.

That’s power. And power always comes with risk.

Most production GraphQL incidents I’ve dealt with weren’t caused by sophisticated attackers.

They were caused by:

• well-meaning frontend engineers

• curious internal users

• third-party clients doing “creative” things

• or us, six months later, after the schema evolved

In other words: most GraphQL problems are self-inflicted.

This post isn’t about theoretical vulnerabilities. It’s about how GraphQL APIs actually get abused in practice, what actually stops expensive queries, and where popular defenses help  or don’t.

If you’re responsible for a production GraphQL API, this is the stuff you end up learning the hard way. I’m trying to save you a few 2am incidents.

Why GraphQL Can Be Abused

Expensive query shapes

GraphQL lets clients nest fields arbitrarily deep and request large sibling sets at each level.

Individually, these look harmless:

Nothing illegal here. No introspection. No auth bypass.

But I’ve seen queries like this take down services.

Why? Because the cost isn’t obvious from the query text. It explodes combinatorially once it hits resolvers and databases.

Depth × width × list sizes × resolver behavior = surprise outage.

This is the fundamental GraphQL risk: the most expensive queries don’t look scary.

Resolver amplification and the N+1 disaster

Every GraphQL engineer learns about N+1 queries. Many teams still ship them.

The common pattern:

• hits the database

• hits the database

• hits the database

• Repeat… a lot

Now add lists.

A single query turns into:

• 1 query for users

• N queries for posts

• N×M queries for comments

• N×M×K queries for authors

I’ve seen “simple” queries trigger tens of thousands of DB calls.

From the outside, it looks like a single request. From the inside, it’s a fork bomb.

This is why GraphQL abuse often bypasses traditional rate limiting. One request can be worse than 10,000 REST calls.

Large lists and pagination abuse

Pagination is where good intentions go to die.

The classic mistake:

“But nobody would do that.”

Someone will. Or your own data will grow until someone accidentally does.

Large lists are the easiest way to accidentally DOS yourself. They’re also the hardest to notice in reviews, because they feel like a product decision, not a security issue.

They are absolutely a security issue.

Schema discovery via introspection

Introspection lets clients ask your API what it can do.

• That’s great for developer experience.
• It’s also great for attackers.

With introspection, someone can:

• map your entire schema

• see which types reference which

• find “interesting” fields (admin flags, audit logs, billing data)

• craft expensive queries offline

Introspection doesn’t execute business logic. But it removes guesswork.

introspection is not the vulnerability. It’s an accelerant.

Authorization mistakes across nested graphs

This is the one that causes data breaches.

A field is protected at the top level:

Why? Because auth was implemented on the root resolver, not the field.

In REST, this mistake is harder to make. In GraphQL, it’s common  especially as schemas evolve.

I’ve seen teams say “we have auth” while leaking sensitive data through three hops they forgot to check.

Useful, Dangerous, and Often Misunderstood

Introspection answers one question: “What does this GraphQL API look like?”

That’s it.

It does not:

• bypass auth

• execute resolvers

• fetch data

• magically expose secrets

But it does give attackers a detailed map.

What introspection really enables

With introspection, an attacker can:

• enumerate all types and fields

• see which fields return lists

• identify deeply nested paths

• spot fields with vague names

• generate worst-case queries without trial and error

Without introspection, they’d still be able to attack  just more slowly.

That’s the key tradeoff.

When to disable it

I generally disable introspection in:

• public production APIs

• APIs with anonymous access

• APIs exposed to untrusted third parties

Especially if:

• the schema is large

• the data is sensitive

• query cost controls are immature

Disabling introspection doesn’t make you “secure”. It just raises the bar.

When to restrict it

A common middle ground:

• enable introspection for authenticated users

• disable it for anonymous requests

• or only allow it from internal IP ranges

This preserves developer experience without handing out a free map to the world.

When to leave it on

• For internal tools and trusted clients, introspection is usually fine.
• If everyone who can hit the API is already authenticated, rate-limited, and audited, introspection is not your biggest problem.
• The mistake is treating introspection as the security decision. It’s one knob among many.

What Actually Stops Expensive GraphQL Queries

This is where theory and reality diverge.

Why depth limiting alone is insufficient

Depth limits are popular because they’re easy to explain.

Max depth

7.

Sounds reasonable. Feels safe.

It’s not enough.

• You can write a shallow query that’s insanely expensive:Cost: depends on your data size. Could be catastrophic.
• Depth limits stop some pathological cases. They do nothing against wide queries or large lists.
• I’ve seen teams proudly say “we limit depth” right before an outage caused by a depth-3 query.

Why query cost / complexity limits matter more

Cost analysis tries to answer the real question:

“How expensive will this query be when executed?”

A decent cost model considers:

• field weights

• list multipliers

• nested list expansion

• pagination arguments

For example:

• costs 10

• costs 5 × list size

• costs 3 × list size

Suddenly that harmless query has a cost of 50,000 and gets rejected.

This is the single most effective GraphQL defense I’ve used.

It’s also painful to tune.

• You will get false positives.
• You will argue about weights.
• Someone will complain their query was blocked.

Do it anyway.

Pagination limits save you from yourself

Always enforce:

• default page sizes

• maximum page sizes

Hard limits. Server-side. Non-negotiable.

• If your API accepts , it should clamp it.
• I don’t care how “internal” the API is. Internal clients grow. Data grows. Assumptions break.
• Unlimited pagination is a loaded gun pointed at your database.

Timeouts and rate limits still matter

GraphQL doesn’t replace basic API hygiene.

You still need:

• request timeouts

• per-user rate limits

• concurrency limits

Especially because a single GraphQL request can monopolize resources.

I’ve seen systems where one slow query blocks the entire Node.js event loop. No amount of query analysis fixes that.

Defense in depth matters.

Poor resolver design causes “invisible” explosions

Here’s the uncomfortable truth: no amount of query limiting saves bad resolvers.

If a resolver:

• does synchronous I/O

• makes per-item network calls

• loads huge blobs into memory

• ignores batching and caching

Then even “cheap” queries can hurt you.

I’ve debugged incidents where the query cost looked fine  and the resolver implementation was the real culprit.

GraphQL security isn’t just about the query. It’s about the execution.

Persisted Queries: Why They Help and Why They’re Not Magic

What persisted queries are

Instead of clients sending full GraphQL query text every time, they send:

• a hash (or ID)

• the server looks up the query

• executes the known, pre-approved document

That’s it.

Why allowlisted queries dramatically reduce abuse

If the server only executes known queries:

• no ad-hoc query shapes

• no surprise nesting

• no exploration

• no “creative” abuse

This is huge.

I’ve seen public GraphQL APIs go from constant abuse to near-zero just by moving to allowlist-only persisted queries.

It turns GraphQL into something closer to REST  with better tooling.

Allowlist-only vs APQ fallback

There are two common modes:

Allowlist-only

• Unknown queries are rejected

• Strongest protection

• Best for mobile apps and public clients

Automatic Persisted Queries (APQ) with fallback

• Client sends hash

• If missing, sends full query to register it

• More flexible

• More dangerous if public

Public APQ registration is a footgun. You’ve just let anyone upload arbitrary queries.

If you use APQ:

• restrict registration

• authenticate it

• rate-limit it aggressively

How persisted queries help with monitoring and performance

Persisted queries give you:

• stable identifiers

• per-query metrics

• easier caching

• clearer dashboards

Instead of “some random query was slow”, you get:

“Query is slow after the last release.”

This alone is worth it.

Where persisted queries don’t protect you

Persisted queries are not magic.

They don’t fix:

• bad resolver implementations

• missing authorization

• overly large variables

• abusive variable values (first: 100000)

• expensive queries you allowed

I’ve seen teams allowlist a monster query and then act surprised when it hurts them.

Persisted queries reduce the attack surface. They don’t eliminate responsibility.

A Practical Baseline Setup

Public clients web, mobile, third-party

• Persisted queries (allowlist-only)

• No public introspection

• Strict cost limits

• Hard pagination caps

• Rate limits per user/token

• Timeouts

• Logging of rejected queries

This is non-negotiable if you care about uptime.

Internal tools

• Authenticated introspection

• Cost limits (looser)

• Pagination caps

• Monitoring for slow queries

Internal users can break things just as effectively  they just apologize afterward.

Mobile apps

• Persisted queries

• Versioned allowlists

• Aggressive limits

• Server-side validation of variables

Mobile clients live forever. Assume old versions will keep sending requests.

Common Mistakes I See Over and Over

• Depth limits without cost limits

• Unlimited pagination “because the UI won’t do that”

• Public APQ registration

• Auth checks only at the root level

• No field-level authorization

• Zero visibility into which queries are expensive

• Treating introspection as the main threat

• Shipping GraphQL without understanding resolver behavior

None of these are theoretical. I’ve seen all of them in production.

Usually more than one at the same time.

---

You Might Be Interested In

• Dependency Confusion Prevention: Naming, Registries, And Ci Safeguards
• How Phishing Attacks Trick Users?
• Sigstore/cosign Basics: Signing Container Images Without Managing Keys
• Ai In Threat Detection: How It Works Basics?
• Slsa Levels Explained: What Level 2 Looks Like For Real Teams

---

Conclusion

GraphQL doesn’t fail because it’s insecure by design. It fails because it gives clients real power, and that power often goes unconstrained. When things break in production, it’s rarely due to some clever exploit  it’s because an expensive query shape slipped through, a resolver amplified work in ways no one anticipated, or a “temporary” limit was never enforced. These issues are predictable, repeatable, and almost always avoidable once you understand how GraphQL actually executes.

The goal of GraphQL security isn’t to lock everything down or remove flexibility. It’s to put intentional boundaries around that flexibility. Introspection, depth limits, cost analysis, pagination caps, and persisted queries all play a role, but none of them work in isolation. What matters is defense in depth, visibility into real query behavior, and honest acceptance that your schema will be used in ways you didn’t expect. If you design with that reality in mind, GraphQL becomes not just powerful, but dependable  and far less likely to wake you up in the middle of the night.

FAQs  about Graphql Security Basics: Introspection, Depth Limiting, And Persisted Queries

Should I disable GraphQL introspection in production?

If your GraphQL endpoint is public or reachable by untrusted clients, I usually disable introspection in production. Not because introspection is a “hack,” but because it hands out a complete map of your API: types, fields, relationships, and the best places to probe for deep/wide query shapes. Without it, attackers can still hurt you, but they have to guess more, iterate slower, and they’re more likely to trip rate limits and monitoring before they get clever.

That said, disabling introspection can be a productivity tax if you don’t replace it with a better workflow. What tends to work is: keep introspection enabled in non-prod, and in prod only allow it for authenticated staff roles, internal networks, or a separate “developer schema” endpoint. The mistake is treating introspection like the main security control. It’s not. It’s a convenience feature you can gate depending on how exposed your API is.

Is depth limiting enough to prevent expensive GraphQL queries?

No. Depth limiting stops one specific shape of abuse super deep nesting, but it does almost nothing for the most common “looks harmless but explodes” scenarios: wide selection sets and large lists. A depth-4 query can still be catastrophic if it asks for a big list of users, then posts for each user, then comments for each post. The query doesn’t need to be deep to multiply work; it just needs list fan-out plus resolvers that aren’t designed to handle it.

Depth limits are still useful as a guardrail, but they’re not the guardrail people think they are. If you only implement depth limiting, you’ll eventually get burned by a shallow query that turns into a DB storm. The real protection comes from combining depth limits with cost/complexity analysis, strict pagination caps, and sane resolver behavior (batching + avoiding per-item I/O).

What’s the difference between query depth limits and query cost/complexity limits?

Depth limits count how many nested field levels a query has. It’s basically a structural rule: “no query can be deeper than N.” That’s easy to explain and easy to implement, but it’s a blunt instrument. It doesn’t understand lists, fan-out, or expensive fields. A query that’s “shallow” can still be massively expensive if it requests large lists or triggers N+1 patterns.

Cost/complexity limits try to estimate the actual execution cost. They factor in things like list multipliers (page size), nested lists, field weights, and sometimes even custom rules for known-expensive fields (search, aggregations, cross-service calls). They’re harder to tune, and you’ll deal with false positives, but in practice they catch the queries that really take systems down. Depth is a decent seatbelt. Cost limits are the airbags.

Do persisted queries make GraphQL secure?

Persisted queries help a lot, but they don’t magically make your API secure. Their biggest win is cutting off ad-hoc query shapes: if the server only executes an allowlisted set of query documents, you eliminate most exploration, a lot of abuse, and a whole category of “someone found a gnarly query shape we never tested.” Operationally, they also improve observability because you can track performance by query ID instead of trying to dedupe raw query text.

But persisted queries don’t fix authorization, and they don’t fix bad resolvers. If an allowlisted query is expensive, it’s still expensive. If a query lets users access data they shouldn’t through nested paths, persisted queries won’t save you. And variables still matter: even with persisted queries, you must clamp pagination args, validate inputs, and rate-limit. Persisted queries reduce the attack surface. They don’t replace execution controls and good schema/resolver design.

What should I do if my GraphQL API is slow even with limits in place?

First, assume the limits are doing their job and your execution is the problem. I’ve seen “safe” queries pass depth/cost checks and still melt services because resolvers do per-item work (N+1), make synchronous network calls, or pull huge objects into memory. The fastest way to find the culprit is to add per-field timing (or at least per-resolver timing) and correlate slow requests to specific fields and paths. If you can’t answer “which resolver is slow,” you’re debugging blind.

Once you’ve identified hotspots, the fixes are usually boring but effective: batch loads with DataLoader-style patterns, add caching at the right layer (request-level, object-level, or cross-request where safe), enforce pagination everywhere, and move heavy computations out of resolvers. Also check that your cost model reflects reality if a “cheap” field actually triggers an expensive search or a cross-service fan-out, weight it accordingly or gate it behind stricter rules. Limits prevent the worst abuse; good resolver engineering prevents the everyday pain.