Post cover image
Hacking GraphQL APIs: A Practical Guide for Pentesters

June 29, 2026

Finding Hidden GraphQL Endpoints | Hacking GraphQL APIs — Part 2

This is Part 2 of an ongoing series where we’ll learn GraphQL from an attacker’s perspective. Each article builds on the previous one, so…

By Vineet Singh

3 min read

This is Part 2 of an ongoing series where we'll learn GraphQL from an attacker's perspective. Each article builds on the previous one, so if you're new to GraphQL, this is the perfect place to start. Part 1 — https://vineet08.medium.com/hacking-graphql-apis-a-practical-guide-for-pentesters-part-1-c18ba7efbbdb

Finding Hidden GraphQL Endpoints

Imagine this.

You've just received a new target for a pentest.

You open Burp Suite, configure your browser, log in to the application and start clicking around.

After spending ten minutes exploring different pages, something feels… different.

You're not seeing requests like:

GET /users
GET /profile
GET /orders

Instead, almost every request looks like this:

POST /graphql

Nice.

You already know the application is using GraphQL.

But here's the question.

What if you never saw that request?

What if the GraphQL endpoint isn't obvious?

What if the developers tried to hide it?

Can you still find it?

The answer is yes.

And in many bug bounty programs, finding the GraphQL endpoint is actually the first challenge.

Let's see how.

Why This Matters

Finding the endpoint sounds like a small task.

It isn't.

No endpoint means:

  • No introspection
  • No schema discovery
  • No authorization testing
  • No mutations
  • No GraphQL exploitation

Everything starts here.

If you can't find the endpoint, the assessment usually ends before it even begins.

Method 1 — Let Burp Do the Work

The first thing I always do is…

Nothing fancy.

I simply browse the application while Burp Suite is running.

You'd be surprised how many GraphQL endpoints reveal themselves just by clicking around.

Things I usually try:

  • Login
  • Registration
  • Profile page
  • Dashboard
  • Search
  • Notifications
  • Settings

While doing this, keep an eye on Burp's HTTP history.

If you suddenly notice something like:

POST /graphql

Congratulations.

You already have your first target.

Sometimes bug hunting really is this simple.

Method 2 — Guess Common Endpoints

Developers don't always use /graphql.

Some common endpoint names I've encountered include:

/graphql
/graphql/
/api/graphql
/graphql/v1
/query
/gql
/api/query
/graphql-server

When nothing appears during browsing, I normally perform a quick directory fuzz.

Using ffuf

ffuf -u https://target.com/FUZZ -w graphql-endpoints.txt -mc 200

Using feroxbuster

feroxbuster -u https://target.com -w graphql-endpoints.txt -x js,json

Method 3 — JavaScript Files

This is probably my favorite technique.

Whenever I receive a new target, I spend a surprising amount of time reading JavaScript files.

Why?

Because frontend developers have a habit of leaving interesting things there.

Sometimes you'll find:

const GRAPHQL_URL = "/graphql";

Sometimes:

fetch("/api/graphql")

Sometimes even:

https://api.target.com/graphql

Developers aren't trying to hide anything.

They're simply building the application.

We're just reading what the browser already downloaded.

If you're not looking at JavaScript during recon, you're probably missing valuable information.

Method 4 — Developer Tools

Open Chrome DevTools.

Navigate to the Network tab.

Refresh the page.

Filter requests using the word:

graphql

You might immediately discover requests going to a GraphQL endpoint.

Sometimes Burp misses something during manual browsing.

The browser's developer tools can help fill those gaps.

Method 5 — Look for GraphiQL and Playground

Developers often leave debugging interfaces enabled.

Some common paths worth checking are:

/graphiql
/playground
/graphql-playground
/graphql/console

If you're lucky, you'll be greeted by an interactive GraphQL interface.

It's basically a playground where developers test their own APIs.

And yes…

Pentesters love it too.

Method 6 — Wayback Machine & Historical URLs

Sometimes an endpoint existed months ago but isn't linked anymore.

Historical data can still reveal it.

Tools I commonly use include:

gau

gau target.com | grep graphql

waybackurls

waybackurls target.com | grep graphql

Katana

katana -u https://target.com | grep graphql

Even if the endpoint no longer appears in the application, archived URLs may still expose its location.

Method 7 — Error Messages

This one is more accidental than intentional.

Sometimes developers expose GraphQL without realizing it.

Visiting random endpoints or sending malformed requests can trigger responses like:

Must provide query string.

or

GraphQL query missing.

That single error message tells you a lot.

You just found GraphQL.

My Recon Workflow

Whenever I suspect an application uses GraphQL, this is roughly the order I follow.

Browse the application
        │
        ▼
Burp HTTP History
        │
        ▼
JavaScript Files
        │
        ▼
Developer Tools
        │
        ▼
Common Endpoint Guessing
        │
        ▼
GraphiQL / Playground
        │
        ▼
Historical URLs

Notice something?

I don't immediately start fuzzing.

Most of the time, simple observation gives me the answer.

Pentester's Notes

Whenever you're testing a modern web application:

✅ Keep Burp running from the beginning.

✅ Spend time reading JavaScript files.

✅ Check browser Developer Tools.

✅ Try common GraphQL paths.

✅ Look for GraphiQL or Playground.

✅ Don't ignore strange error messages.

Recon is usually the easiest part to skip.

It's also where many interesting discoveries begin.

Mini Challenge

Visit any application that you know uses GraphQL.

Without using Google or reading documentation, try answering these questions:

  • Can you identify the endpoint?
  • Did you find it through Burp?
  • JavaScript?
  • Browser DevTools?
  • Historical URLs?

Write down which technique worked.

You'll start noticing that every application leaves different clues.

What's Next?

Now that you've successfully found a GraphQL endpoint, the obvious question becomes:

How do you actually communicate with it?

In the next article, we'll stop doing reconnaissance and start interacting with GraphQL for the first time.

We'll build our first queries, understand GraphQL request structure, and use Burp Suite to communicate directly with the server.

See you in Part 3.