GraphQL Bug Bounty 2026 — Introspection Abuse, Injection & Broken Authorization | BB Day 22

Finding GraphQL Endpoints

The first thing you learn about GraphQL hunting is that finding the endpoint is itself part of the work. There’s no Swagger UI at a predictable URL. Finding the endpoint is the first step. The most reliable method is monitoring your browser’s Network tab during normal application use: GraphQL requests appear as POST requests with a JSON body containing a query field. Burp Suite’s HTTP history captures these automatically when you proxy the application.

For applications where you haven’t spotted active GraphQL traffic, probe common endpoint paths. Send a POST request with body {"query": "{ __typename }"} to each path. A GraphQL endpoint returns {"data": {"__typename": "Query"}} on success, or a structured JSON error referencing GraphQL on any valid endpoint that rejected your query. Both responses confirm the endpoint exists. Non-GraphQL paths return HTML error pages or irrelevant JSON that doesn’t match this pattern.

GraphQL Introspection — The Free Schema Dump

Introspection is a GraphQL feature that allows clients to query the schema itself — asking “what queries and mutations are available, what arguments do they take, what types do they return?” When enabled in production (which it should not be), introspection hands the attacker a complete blueprint of the backend API including operations that are never used by the frontend application.

The full introspection query is verbose, but the critical sections are the type list (all object types and their fields) and the mutation type (all write operations). Fields named adminToken, internalUserId, bypassAuth, or mutations named createAdminUser flag themselves as high-priority targets. Even “safe” schemas reveal ID fields on user and resource objects — the starting point for IDOR testing.

IDOR via Direct Object IDs

GraphQL queries frequently accept direct object IDs as arguments. When authorization is implemented at the application layer rather than per-resolver, the API may return any object’s data for any valid ID regardless of which user is making the request. Testing GraphQL IDOR follows the same pattern as REST IDOR: create two test accounts, retrieve your own object’s ID, then use Account B to query Account A’s data using that ID.

Broken Authorization on Mutations

GraphQL mutations — the write operations — are where broken authorization causes the most damage. Developers sometimes implement read authorization carefully (checking whether a user can see data) but miss authorization on mutations (checking whether a user can change data). Mutations worth testing: password reset for another user’s account, privilege escalation (changing your own role field), accessing admin-only mutations visible in the schema but not in the UI, and deleting or modifying other users’ resources.

The schema from introspection reveals every mutation even if the frontend application never calls them. An assignAdminRole mutation that exists in the schema but is never called from the UI is almost certainly not properly access-controlled — developers often forget to add authorization checks to mutations that aren’t exposed to users. This is the highest-ROI attack surface from introspection: mutations that exist but are invisible.

GraphQL Injection

GraphQL arguments that are passed to backend database queries or system operations are injection vectors. The GraphQL layer itself is not injectable (it parses structured query syntax), but the arguments within queries are passed to resolvers that often construct SQL, NoSQL, or other queries. SQL injection in GraphQL: test string arguments with ', ' OR '1'='1, and ' OR SLEEP(5)--. NoSQL injection: test object arguments with {"$gt": ""} and {"$where": "1==1"}. SSRF: test URL arguments with your Burp Collaborator callback URL.

Batch Query Abuse for Rate Limit Bypass

GraphQL supports aliased queries — sending multiple operations with different aliases in a single HTTP request. Rate limiting typically operates at the HTTP request level: X requests per minute per IP. Batch query abuse exploits this by sending 100 operations as aliases in one HTTP request. The server counts one request but processes 100 operations. This is particularly impactful against OTP verification endpoints, login mutation rate limiting, and any operation where the protection relies on HTTP request counting.

GraphQL Real Finding — IDOR to Account Takeover Chain

Let me walk you through exactly how a real GraphQL critical finding looks, because the theory only makes sense when you see the attack path end to end.

The target had disabled GraphQL introspection — a common security measure teams implement when they think it stops enumeration. It doesn’t. I ran the __type query manually and got the schema back. The backend was validating the introspection query keyword but not the underlying type system queries. First finding.

Once I had the schema, I mapped the user-related queries. There was a getUser(id: Int) query that returned full user profile data — email, phone, address, linked payment methods. The ID was a sequential integer. No authorisation check on the resolver beyond “authenticated user.” I queried ID 1. Got the admin’s full profile. Critical IDOR, full account takeover chain, remediated same day.

The report on that finding was straightforward: here’s the query, here’s the response with another user’s payment methods, here’s the CVSS score (9.3), here’s the remediation — add authorisation check to the resolver comparing the requested user ID against the authenticated session’s user ID. Programme paid within 48 hours. That’s what GraphQL IDOR looks like on a real programme.