GraphQL is quickly becoming the standard for modern APIs, but as the saying goes, "with great power comes great responsibility" — or in our case, great vulnerabilities. If you are coming from PortSwigger's GraphQL labs, you already know the basics and easy to understandable this blog;

I hope this help you as well , it help me to recall , everything from the PortSwigger learning path, community tools, GitHub wordlists, and advanced techniques like alias overloading and CSRF.

Strap in. This will be long, so consider this "PART 1"

1. The "What" & "Why": GraphQL Attack Surface

Unlike REST, GraphQL has a single endpoint (usually /graphql). The client dictates exactly what data to fetch.

None
REST vs GraphQL API .png

7 Deadly Sins of GraphQL you must look for:

Introspection (Info Leak) — Querying __schema to get the entire API blueprint. Full disclosure of hidden fields, mutations, and arguments.

Field Suggestions — When introspection is "off," error messages suggest correct field names. Schema recovery without formal introspection.

IDOR & BOLA — Manipulating object IDs in queries to access unauthorized data. Horizontal/Vertical privilege escalation.

Deep Query DoS (Aliases) — Using nested queries or aliases to overload the server. Denial of Service, application crash.

Batch Queries — Sending multiple operations in one HTTP request. Bypassing rate limits, brute-forcing faster.

GraphQL CSRF — Forcing a victim's browser to send a mutation. Account takeover, data modification.

Injection (SQL/NoSQL) — Injecting code via query arguments in resolvers. Data theft, authentication bypass.

2. Discovery: Finding the Hidden Endpoint

Before you hack it, you have to find it. GraphQL endpoints don't always live at /graphql.

Technique 1: The Universal Ping Send a POST request with {"query": "{__typename}"}. If it returns {"data": {"__typename": "Query"}}, you have hit a live GraphQL endpoint .

Technique 2: Wordlist Fuzzing Use specialized wordlists. The community standard is the SecLists GraphQL discovery list .

ffuf -u https://target.com/FUZZ -w https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/graphql.txt

Technique 3: The JS Crawl (Modern Approach) Modern apps bundle the endpoint in JS files. Use tools like Graphinder to crawl JS and find hidden endpoints automatically .

graphinder -d https://target.com -o endpoints.txt

Technique 4: Manual Analysis (The Most Overlooked & Fastest)

Most hunters directly jump into Burp Suite and start testing every request. Stop. Try this first.

Go to your target site (where you have permission). Don't run a scanner yet. Instead, do this:

  1. Undersand & Scroll — Spend 5–10 minutes just using the application. Click around, login, check your profile, make a purchase, edit settings. Understand the logic and features first.
  2. Open DevTools (F12) — Go to the Network tab.
  3. Filter & Observe — Reload the page or trigger actions. Look for requests with names like:

api, graphql, query, data, v1, v2

  1. Check the Response Preview — Click on any suspicious XHR/fetch request. In the Preview or Response tab, look for GraphQL keywords:
  • "data", "query", "mutation", "__typename", "errors"
  • array
  1. Inspect JavaScript Files — In the Network tab, filter by .js files. Search through them for strings like:
  • /graphql, query {, mutation {, useQuery(, apollo

Real-world example: A small main.chunk.js file might contain:

const API_ENDPOINT = "https://internal-api.target.com/graphql/internal";

And there's your hidden endpoint, without a single tool.

Why this works: Developers often hardcode endpoints in frontend JS bundles. Automated scanners miss these because they don't execute JavaScript or follow logic flows. Your eyes + DevTools will find things scanners never will.

Pro tip: Use the "Search" feature in Firefox DevTools (Ctrl+Shift+F) across all network requests to search for .graphql or /query across every response body.

3. Introspection & Schema Dumping

Once you find the endpoint, the first thing you do is ask the server for its blueprint.

The Query: Copy the classic introspection query (the full one with FullType fragments) . Send it via Burp or Curl.

The Tools:

  • InQL (Burp Extension): Automates schema dumping and generates targeted queries for every field it finds .
  • GraphQL Voyager: Paste the JSON response here. It turns the schema into an interactive graph. You will visually see the connection between User and AdminPanel .

What if Introspection is Disabled? Don't panic. There are three bypasses:

  1. Clairvoyance: A tool that uses field suggestions errors to brute-force the schema even when introspection is blocked .
  2. GraphQL Raider: Use this Burp extension to run a "Bulk Find" operation to guess field names .
  3. Error Leakage: If you send a malformed query, does the error message show the path? This can leak schema structure .

4. Attacking the Logic: IDOR & Broken Auth

GraphQL is terrifying for authorization because it has a single endpoint. Access control must be checked at the resolver level (field by field), which developers often forget.

The IDOR Pattern: Look at the queries you found in the schema. If you see getUser(id: 123) or invoice(number: 456):

  1. Send the query as User A.
  2. Change the ID to User B's ID.
  3. If you see User B's data? Critical vulnerability found.

Mutations (The Write Operations): This is where you take over accounts.

  • Mass Assignment: Does the updateUser mutation accept a role field? Add "role": "ADMIN" to your request. The backend might save it without validation .

5. Advanced Exploitation: Resource Exhaustion & CSRF

Alias Overloading (DoS): In GraphQL, you can ask for the same field multiple times using aliases (a1: user, a2: user). Attackers can send thousands of aliases in one request. If the server doesn't limit query costs, you can DoS it with a single HTTP packet .

Batching vs. Rate Limiting: Rate limits usually apply to HTTP requests, not operations. Batching allows you to send 100 login attempts inside 1 HTTP request, bypassing "1 attempt per second" rules .

GraphQL CSRF (The 2024+ Bypass): Many devs think application/json protects them. It does not. Attackers can use a <form> with enctype="text/plain" or a simple JS fetch to send valid JSON to the GraphQL endpoint. If the server uses cookies for auth and lacks CSRF tokens, an attacker can change your email or password via a malicious site .

This all what i learn from portswigger lab and let's learn beyond this…

6. The Ultimate Toolchain & Wordlist Collection

You asked for resources — here is a curated list of everything you need.

🛠️ The Arsenal (Tools)

Tool — Purpose — Why it's the Best

InQL — Burp Schema Analysis — Visualizes relationships, auto-builds queries.

GraphQL Raider — Burp Fuzzing — Edits token values in bulk, tests for auth bypass.

Clairvoyance — Blind Schema Extraction — Recovers schema when introspection is OFF using errors.

GraphQLmap — Scripting/Exploit — Python tool for injection and batch attacks (SQLmap style).

GQLMap — Automation — Auto-detects endpoints, crawls JS, fuzzes mutations.

api.sh — All-in-One Scanner — Checks GraphQL, REST, WebSockets, and Rate Bypass in one script. || This tool is not checked but i found this so i added here.

📝 The Wordlist (The Secret Sauce)

Generic wordlists miss GraphQL naming conventions. Use these specialized lists:

Escape GraphQL Wordlist: Collected from 60,000+ real schemas. Contains specific operation names and field names .

SecLists GraphQL.txt: Best for endpoint discovery .

TimBoBN Wordlist: Good for backup files and API specific fuzzing .

Still Don't reliance on Wordlist or tool ; while in testing and practicing lab. I found that tool are not detecting properly all the time. They miss sometimes and Public Wordlist are just a base list for me/us. We have to add some keyword , Although it my observation; make me correct if I am not right!!

🔬 The Learning & Defense

  • GraphQL Armor: A security layer to protect Apollo servers (useful to know as a defender) .

7. The Real-World Chain (Scenario)

Imagine you are testing https://redacted.com. Here is how you chain these resources:

  1. Discover: You use ffuf with SecLists/graphql.txt and find /api/public/graphql.
  2. Recon: You run InQL against it. Introspection is OFF.
  3. Resilience: You run Clairvoyance against the endpoint. It uses error messages to brute-force the schema. It finds a mutation: resetPasswordByEmail(email: String!).
  4. Exploit: You try CSRF. You host an HTML page that sends a fetch POST request to that mutation with the victim's email.
  5. Result: You change the admin's password. Critical severity.

Summary Checklist for your Blog

  • Discovery: Use {__typename} and SecLists; don't just guess.
  • Recon: Use InQL to map the attack surface.
  • Authorization: Always test IDOR on every id argument in queries and mutations.
  • Exploitation: Use aliases and batching to break rate limits.
  • Tooling: Keep Clairvoyance and GQLMap in your back pocket for stubborn targets.

GraphQL is not a fad; it is the present. The labs give you the mechanics, but these resources and chains give you the art of the hack. Go break things (ethically)

Clich here for Part 2 : coming soon…