GraphQL Security in 2026: Beyond Introspection

Last updated: April 26, 2026

GraphQL adoption in Indian SaaS doubled between 2023 and 2026. The attack surface has not been examined with the same rigor as REST. GraphQL’s flexibility — single endpoint, client-specified queries, deeply nested types — creates a distinct attack surface that traditional WAFs and API security tools miss. This article covers GraphQL pentest beyond the basic introspection trick: nested query DoS, alias-based brute-forcing, batched query authorisation bypass, the introspection-disabled bypasses, and detection that catches active exploitation.

Beyond “is introspection enabled?”

Most GraphQL pentest articles stop at: enumerate the schema via introspection, find sensitive types, query them directly. That misses 80% of the attack surface. GraphQL’s distinctive vulnerabilities cluster in five categories.

1. Schema enumeration when introspection is disabled

Many production GraphQL endpoints disable introspection. But the schema can often still be inferred:

• Field suggestions — when you query a non-existent field, the server’s error message often suggests valid fields (“Did you mean: userName, userEmail?”). Bruteforceable.
• Tools like clairvoyance automate schema reconstruction from suggestion errors.
• JS bundle analysis — frontend bundles often contain the GraphQL schema. strings app.js | grep "type Query".
• Gateway leaks — Apollo Studio, Hasura, AWS AppSync sometimes leak schema via debug endpoints.

2. Nested query DoS

GraphQL allows arbitrary query depth. A query like:

query {
  user(id: 1) {
    friends {
      friends {
        friends {
          friends { id name }
        }
      }
    }
  }
}

If friends resolves via N+1 database queries, this query alone causes the database to issue billions of queries. Without depth limits, a single attacker request DoSes the backend.

Tools to test: graphql-cop automates depth and complexity testing.

3. Alias-based brute-forcing

GraphQL allows aliasing — running the same field multiple times in one query. Use aliases to bypass per-request rate limiting:

mutation {
  l1: login(user: "admin", pass: "Pass1") { token }
  l2: login(user: "admin", pass: "Pass2") { token }
  l3: login(user: "admin", pass: "Pass3") { token }
  ... (100 attempts in one request)
}

If rate limiting is per-request not per-resolver, you’ve just brute-forced 100 passwords with one HTTP call.

4. Batched query authorisation bypass

Apollo Server supports batched queries — multiple queries in one HTTP request. If the authorisation middleware checks the request, not each query, batching can mix authenticated and unauthenticated queries:

POST /graphql
[
  { "query": "{ me { id } }" },              // legit
  { "query": "{ adminUsers { email pass } }" } // unauthorised
]

Some implementations only check auth on the first query. Catastrophic where present.

5. IDOR via GraphQL

GraphQL’s strong typing makes IDOR feel less likely — but it isn’t. Common pattern:

query { user(id: 12345) { email phoneNumber } }

If the resolver doesn’t verify that the requesting user is allowed to read user 12345, this is IDOR. Test with sequential IDs, your-account vs other-account, predictable UUIDs.

6. Mutation injection

GraphQL mutations modify state. Look for mutations that take object arguments where the server might not validate every field. updateUser(input: { id: 123, role: "admin" }) — if the server doesn’t check that role is editable, role-escalation in one call.

Practical workflow

1. Locate the endpoint. Common paths: /graphql, /api/graphql, /v1/graphql, /query.
2. Test introspection. Send __schema introspection query.
3. If disabled, run clairvoyance against the endpoint to reconstruct schema.
4. Use Burp’s InQL extension to visualise schema and generate query templates.
5. Test depth/complexity limits with deeply nested queries.
6. Test alias batching against authentication endpoints.
7. Test query batching for authorisation enforcement.
8. For each mutation, test field-level authorisation by including unexpected fields.

Detection — what works

• Apollo Server query complexity plugin or equivalent — assign cost weights to fields, reject queries exceeding budget.
• Depth limiting — reject queries deeper than N (typically 5-7).
• Per-resolver rate limiting — count alias-expanded resolver calls, not HTTP requests.
• Batched query disabled in production unless specifically required.
• Introspection disabled in production.
• WAF rules for GraphQL — emerging; AWS WAF and Cloudflare added GraphQL-aware rules in 2024.
• SIEM correlation — GraphQL request logs correlated with backend resource consumption; queries causing disproportionate load are suspect.

How to find your next GraphQL bug

• Test every mutation that takes object input. Try sneaking in isAdmin: true, role: "admin", verified: true.
• If introspection is on, generate query templates with InQL; trace each to backend logic.
• Test alias-batched authentication endpoints — login, password reset, OTP verify.
• Look at frontend queries; they reveal the typical access pattern. Anything not on this pattern is likely under-tested.

Compliance angle

• OWASP API Security Top 10 — GraphQL maps to API1 (auth), API3 (excessive data exposure), API4 (lack of resources / rate limiting), API5 (function-level auth).
• DPDP §8(5) — GraphQL exposing personal data without resolver-level auth is a reasonable-security failure.

The takeaway

GraphQL’s flexibility is its security challenge. Traditional API security thinking — per-endpoint auth, per-request rate limiting — does not map cleanly. The defender’s job is field-level and resolver-level controls, complexity budgeting, and continuous testing of new schema additions. The attacker’s job is to find the resolver that nobody thought to authorise. Apply Burp + InQL to your next GraphQL audit; the findings are usually waiting in the schema.