API Testing with Burp Suite: A Practical Guide

How Is Burp Suite Used for API Testing?

Burp Suite allows security professionals to intercept, modify, and analyze API traffic. This is useful for identifying issues like improper authentication, excessive data exposure, and parameter tampering. When testing APIs, Burp Suite acts as a proxy between the client and the API server, capturing the raw HTTP or HTTPS requests. These requests can be modified and replayed to observe how the API handles different inputs. 

For REST APIs, Burp Suite simplifies the process of inspecting and manipulating request headers, parameters, and payloads. Testers can use the Repeater tool to send customized requests to the API repeatedly, allowing them to analyze how the API reacts to different parameters, inputs, and methods. This helps detect vulnerabilities like SQL injection, command injection, or improper handling of user data. 

Additionally, Burp’s Intruder tool can automate fuzzing by sending a large number of varied payloads to API endpoints, enabling systematic testing for security issues such as authentication bypass or injection flaws.

For GraphQL APIs, Burp Suite offers a dedicated GraphQL tab in the message editor, to simplify viewing and modifying queries. GraphQL introspection queries allow testers to explore the API's schema, revealing available queries and mutations. This schema information helps identify potential vulnerabilities related to overexposure of data or lack of proper access control. 

Related content: Read our guide to API security

Tutorial: Using Burp to Test a GraphQL API

In this tutorial, we will explore how to use Burp Suite to work with GraphQL APIs, focusing on viewing, modifying requests, and accessing GraphQL schema through introspection queries. These instructions are adapted from the official documentation.

Viewing and Modifying GraphQL Requests

Burp Suite simplifies the process of analyzing and modifying GraphQL requests. When Burp detects a GraphQL request, it automatically adds a dedicated GraphQL tab in the message editor. This tab splits the request into two panels:

• Query panel: Displays the GraphQL query itself. This is where you can view and edit the structure of the query, specifying exactly which data to request.
• Variables panel: Lists any variables associated with the GraphQL query. Variables allow for dynamic querying, making this panel useful for testing different input values without modifying the query directly.

For example, if Burp intercepts the following request:

POST /graphql HTTP/1.1
Host: target-site.com
Content-Type: application/json
{
 "query": "{ user(id: 1) { name email } }",
 "variables": {}
}

‍

The Query panel would display:

{

  user(id: 1) {

name  

email

}

}

‍

And the Variables panel would show:

{}

You can modify the query or the variables directly from these panels, allowing you to test various inputs or parameters against the API.

Accessing a GraphQL API Schema with Introspection Queries

GraphQL supports introspection queries, which provide details about the API’s schema, including available queries, mutations, and data types. Burp Suite can generate and send introspection queries, helping you understand the structure of the API and identify potential vulnerabilities.

Here’s how to run an introspection query in Burp Suite:

1. Find the GraphQL endpoint: Browse the application and look for requests to typical GraphQL endpoints such as /graphql, /api/graphql, or /graphql/v1.
2. Insert introspection query: In the Proxy screen, right-click within the GraphQL panel, then select GraphQL as shown below:

1. Now in the GraphQL sub-menu select  Set introspection query. This will insert a predefined introspection query into the request body.
2. Now it will display the introspection query in the same GraphQL panel as shown below:

If the target server allows introspection, the response will include the full schema of the GraphQL API. For example, the response might look like this:

{

    __schema {

        queryType {

            name

        }

        mutationType {

            name

        }

        subscriptionType {

            name

        }

        types {

            ...FullType

        }

        directives {

            name

            description

            locations

            args {

                ...InputValue

            }

        }

    }

}

‍

This schema reveals the available queries and types, which can be useful for determining attack vectors, such as querying for sensitive data or manipulating inputs.

If the introspection query fails, you may need to send a legacy introspection query by selecting GraphQL, then Set legacy introspection query from the same context menu.

Saving GraphQL Queries to the Site Map

After a successful introspection query, you can save the discovered queries for further testing. Right-click anywhere in the Response panel and select GraphQL, then Save GraphQL queries to site map. Each query is stored as a node in the site map, enabling you to explore them later or send them to Burp Suite's Intruder or Repeater tools for deeper investigation.

This method helps in systematically mapping out the attack surface of the GraphQL API, making it easier to find vulnerabilities or test potential security flaws.

Tutorial: Using Burp to Test a REST API 

In this tutorial, we will demonstrate how to test REST APIs using Burp Suite, focusing on intercepting requests, analyzing parameters, and identifying potential vulnerabilities such as SQL injection.

Setting Up the Proxy

To begin testing a REST API, you need to set up Burp Suite to intercept the traffic between your client and the API. Ensure your client (whether it's a web browser or a custom tool) is configured to route all HTTP and HTTPS traffic through Burp Suite's proxy.

Once traffic is proxied through Burp, Burp Suite will intercept and display API requests in the HTTP history tab. For example, if your client sends a GET request to the following URL:

GET /api/users/2 HTTP/1.1

Host: localhost

Burp Suite captures this traffic and allows you to modify or analyze the request further.

Mapping the Attack Surface

If you're performing a black-box test (without access to API documentation), the first step is to map the API's structure. By inspecting the captured requests and responses, you can identify API endpoints and parameters. For example:

GET /api/users/2

In this request, the endpoint is /api/users, and the parameter is 2, representing the user ID. Altering this parameter may allow you to access different user data, which can be useful in identifying potential vulnerabilities.

Testing Parameters in Burp Repeater

To analyze the behavior of API parameters, send the captured request to Repeater. In Burp Suite, right-click the request and choose Send to Repeater. This tool lets you modify and resend the request, providing insights into how the server processes different inputs.

For example, you can change the user ID in the URL:

GET /api/users/3

After sending the modified request, if the server returns a different user, you have confirmed that the parameter is processed dynamically.

Detecting SQL Injection Vulnerabilities

A common vulnerability in REST APIs is SQL injection (SQLi). This occurs when user input is improperly handled by the server, allowing attackers to execute arbitrary SQL commands.

1. In Repeater, test the parameter with simple arithmetic to see if it is evaluated mathematically. For example, modify the parameter as follows:‍

‍GET /api/users/3-2

If the server returns the user data for user 1, it indicates that the parameter is being evaluated as an arithmetic expression. This could be a sign of SQL injection vulnerability.

1. Next, you can test SQL-specific syntax by injecting SQL commands directly into the parameter. For example:

GET /api/users/50-ASCII(1)

This SQL query calculates the value 1 based on the ASCII code for the character '1'. If the server returns data for user 1 without errors, it shows that the input is being interpreted as SQL, confirming a SQL injection vulnerability.

Related content: Read our guide to Burp suite tutorial

Pynt: Ultimate Burp Suite Alternative for API Security Testing

Pynt serves as a powerful alternative to Burp Suite for API security testing, offering automated, context-aware testing specifically designed for APIs. While Burp Suite excels in web security testing, Pynt focuses solely on API traffic and vulnerabilities, making it the ideal solution for modern API-centric applications.

Why Choose Pynt over Burp Suite for APIs?

1. Automated Testing: Pynt eliminates manual efforts by automatically generating security tests based on real API traffic and functional tests, ensuring comprehensive API security coverage.
2. Contextual Learning: Pynt leverages contextual analysis to understand API behavior, detecting business logic vulnerabilities and API-specific risks that might go unnoticed in traditional web testing tools like Burp.
3. Seamless Integration: Pynt integrates directly into CI/CD pipelines, enabling continuous security testing without interrupting development workflows, whereas Burp typically requires more manual testing processes.
4. API Security Focus: Unlike general-purpose tools, Pynt is built specifically for API security, including the ability to detect and secure LLM-powered APIs, a capability beyond traditional web security tools like Burp Suite.

For organizations focused on securing APIs, Pynt provides an automated, scalable, and API-centric solution, positioning itself as a superior alternative to Burp Suite for API security testing.

Start using Pynt with the Burp Extension here