Test REST and GraphQL APIs with Burp Suite (2026)

Burp Suite, the Swiss Army knife for web security testing, can absolutely be your go-to for both REST and GraphQL APIs. It’s not just about finding vulnerabilities; it’s about understanding how your API behaves and exposing its weak points.

Let’s see it in action. Imagine you have a simple GraphQL endpoint at http://localhost:4000/graphql. You want to query for user data.

query GetUser($userId: ID!) {
  user(id: $userId) {
    id
    username
    email
  }
}

And your variables might look like this:

{
  "userId": "123"
}

In Burp’s Proxy tab, you’d configure your browser or client to point to Burp’s listener (default 127.0.0.1:8080). Then, you’d make that GraphQL request. Burp intercepts it.

Here’s what you’d see in the HTTP history:

POST /graphql HTTP/1.1
Host: localhost:4000
Content-Type: application/json
Content-Length: [length]

{
  "query": "query GetUser($userId: ID!) { user(id: $userId) { id username email } }",
  "variables": {
    "userId": "123"
  }
}

Now, the magic. You can right-click on this request in Burp’s HTTP history and send it to various tools.

To Intruder: This is where you’d fuzz parameters. For a REST API endpoint like GET /users/{id}, you’d send the request to Intruder, mark {id} as the payload position, and then load a list of common IDs (e.g., 1, 2, 3, 4, 5, 100, 999, admin, root). You can then analyze the responses for differences in length, status codes, or content to identify valid or invalid IDs.

For GraphQL, it’s a bit more nuanced. You might want to fuzz:

• Field names within the query: If a user can request arbitrary fields, you could try injecting __typename or other introspection queries to gather schema information.
• Input arguments: For a mutation like mutation CreateUser($email: String!) { createUser(email: $email) { id } }, you’d send the request to Intruder, mark the email value as the payload position, and load a list of common email formats, SQL injection payloads, or XSS strings.

To Repeater: This is your manual playground. You can tweak the request endlessly. For a REST API PUT /users/{id}, you could change the JSON payload, the id in the URL, or HTTP headers. For GraphQL, you can modify the query string itself, change variables, or even experiment with sending requests with GET instead of POST (if the server allows it) by appending the query and variables to the URL.

To Scanner: Burp’s Scanner can automatically discover vulnerabilities. For REST APIs, it excels at finding SQL injection, XSS, SSRF, and insecure direct object references (IDOR) by intelligently fuzzing parameters and body content. For GraphQL, its effectiveness depends on how well it can parse the query and identify potential injection points. It’s often more effective to use the Scanner on specific, known input fields rather than trying to have it crawl the entire GraphQL query structure.

The Mental Model: How Burp Sees APIs

Burp Suite fundamentally treats all web traffic as HTTP requests and responses. It doesn’t inherently "understand" REST or GraphQL as distinct protocols beyond the structure of the HTTP messages.

• REST: Burp sees distinct URLs (/users/123, /products/abc) and HTTP methods (GET, POST, PUT, DELETE). It maps vulnerabilities to these specific URL paths and methods. For instance, an IDOR on /users/{id} means if a user requests /users/456 and gets data for user 789, Burp flags it.
• GraphQL: Burp sees a single endpoint (e.g., /graphql) and typically a POST request with a JSON body containing query and variables. Its power here comes from its ability to parse this JSON, identify the query string, and then apply its fuzzing and scanning capabilities to the content of that query string and the values within variables. It treats the GraphQL query language itself as a form of structured data to be manipulated.

This means that when testing GraphQL, you’re often telling Burp where within the JSON payload to focus its attention, rather than relying on Burp to understand the abstract concepts of GraphQL schemas or resolvers directly.

The One Thing Most People Don’t Know

When using Burp’s Scanner against GraphQL, it’s incredibly effective to first use Burp’s "Discover content" feature on your GraphQL endpoint. This can sometimes help Burp identify common query patterns or introspection queries that might be allowed. Then, when you run the active scan, Burp can leverage these discovered patterns to craft more targeted payloads. Without this initial discovery, the scanner might be too generic and miss subtle injection points within complex queries.

The next step is to dive into Burp’s extensions, particularly those designed to enhance GraphQL testing, which can unlock even deeper analysis capabilities.