Burp Suite API Testing: Security Testing REST and GraphQL APIs

Web application security testing with Burp is intuitive when there's a browser to proxy. API testing requires a different setup — no browser, no HTML rendering, just HTTP requests and JSON responses. Burp handles this well, but the workflow is different.

This guide covers authorized security testing only. Test APIs you own or have explicit permission to test.

Setting Up for API Testing

Option 1: Proxy Your API Client

The simplest approach: configure your API client to use Burp as a proxy.

Postman:

• Settings → Proxy → Manual proxy configuration
• Host: 127.0.0.1, Port: 8080
• Disable SSL certificate verification OR install Burp's CA cert

cURL:

curl -x http://127.0.0.1:8080 --insecure https://api.example.com/users

Python requests:

import requests
proxies = {"http": "http://127.0.0.1:8080", "https": "http://127.0.0.1:8080"}
response = requests.get("https://api.example.com/users", proxies=proxies, verify=False)

Once proxied, API requests appear in Burp's HTTP History just like browser traffic.

Option 2: Import an OpenAPI/Swagger Definition

Burp Professional can generate requests directly from an OpenAPI spec:

1. Target → Site Map → right-click → Import OpenAPI definition
2. Provide the spec URL or paste the JSON/YAML
3. Burp generates requests for all defined endpoints
4. Configure authentication and send requests to populate the site map

This is faster than proxying — you get coverage of all documented endpoints without manual browsing.

Option 3: Build Requests Manually in Repeater

For undocumented APIs or quick tests:

1. Go to Repeater
2. Set the target host/port
3. Write the HTTP request directly:

POST /api/v1/users/123/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
Content-Type: application/json

{"name": "Test User", "bio": "Test bio"}

Authentication Setup

Most APIs require authentication. Configure it once in Burp:

Bearer token (Repeater): Add the Authorization header to each request manually, or use Session Handling Rules to inject it automatically.

Session Handling Rules (Professional):

1. Project → Session handling rules → Add
2. Configure a rule that adds the token header to all in-scope requests
3. Now every request Burp sends includes the auth token automatically — useful for scanning

OAuth flow: Configure Burp to handle OAuth redirects. Use the proxy to capture the token after login, then use that token in subsequent requests.

Testing Authentication and Authorization

API authentication vulnerabilities are common and high-impact.

Testing JWT Tokens

Install the JWT Editor extension from the BApp Store:

1. Capture a request with a JWT
2. Go to the JWT Editor tab in Repeater
3. Try these attacks:
   • Algorithm confusion (none): Change alg to none and remove the signature — some libraries accept unsigned tokens
   • Algorithm confusion (RS256→HS256): Change the algorithm and sign with the server's public key as HMAC secret
   • Weak secret brute force: Use hashcat or jwt-cracker against a captured token

Testing for IDOR (Insecure Direct Object Reference)

APIs frequently expose user or resource IDs:

GET /api/users/123/profile
GET /api/orders/456/details
GET /api/documents/789

Test with Intruder:

1. Capture a request with your own ID (e.g., 123)
2. Send to Intruder → mark the ID position
3. Use Numbers payload type: test IDs 1–1000
4. Compare response lengths — longer responses may contain other users' data
5. Look for 200 responses that return data (vs. 403/404)

Testing Horizontal vs Vertical Privilege Escalation

With two test accounts (User A and User B):

1. Log in as User A, capture requests
2. Take requests that modify or read User A's data
3. Swap in User B's resource IDs
4. Check whether User A can read/modify User B's data (horizontal escalation)
5. If the API has role-based access, test whether low-privilege tokens can access high-privilege endpoints (vertical escalation)

Testing for Injection Vulnerabilities

API parameters are injection targets just like HTML form fields.

SQL Injection in API Parameters

Test URL parameters, JSON body fields, and headers:

{"user_id": "1 OR 1=1--"}
{"search": "' UNION SELECT * FROM users--"}
{"filter": {"id": {"$gt": "0"}}}  // NoSQL injection

In Repeater, modify parameters manually. For systematic testing, send to Intruder with an SQL injection wordlist.

Look for:

• SQL error messages in responses
• Response length changes (extra data returned)
• Different behavior compared to non-injected requests

Command Injection

Look for parameters that might be passed to system commands:

{"filename": "report.pdf; ls -la"}
{"ip": "127.0.0.1 | cat /etc/passwd"}
{"format": "pdf$(id)"}

SSRF (Server-Side Request Forgery)

If the API accepts URLs (webhooks, image fetch, file import):

{"webhook_url": "http://169.254.169.254/latest/meta-data/"}
{"image_url": "http://internal.service/admin"}
{"callback": "http://your-burp-collaborator.burpcollaborator.net"}

Use Burp Collaborator (Professional) to detect out-of-band SSRF — the target server makes a DNS/HTTP request to your Collaborator payload even if the response doesn't reveal it.

Testing GraphQL APIs

GraphQL presents a unique attack surface.

Introspection

First, check if introspection is enabled:

query {
  __schema {
    types {
      name
      fields {
        name
      }
    }
  }
}

If it returns a full schema, you have a complete map of the API. This is a feature, not a bug, but production APIs sometimes leave it enabled inadvertently.

GraphQL Injection

Test string arguments for injection:

query {
  user(id: "1 OR 1=1") {
    name
    email
  }
}

GraphQL Authorization

Test whether field-level authorization is enforced:

# With your user token, try accessing admin fields
query {
  users {
    id
    email
    passwordHash  # Should be admin-only
    internalNotes  # Should be admin-only
  }
}

Scanning APIs in Burp Professional

After populating the site map via proxying or OpenAPI import:

1. Right-click your target in Site Map → Actively scan this host
2. Configure authentication in scan settings
3. Review scan results in Target → Issues

The scanner tests all discovered parameters for injection, authentication issues, and security misconfigurations.

Organizing API Tests

As you test, annotate interesting requests:

1. In HTTP History, right-click a request → Add comment
2. Or Highlight with a color (right-click → Highlight)

Use colors consistently: red for confirmed vulnerabilities, orange for potential issues, yellow for interesting endpoints to revisit.

Reporting

After testing, generate a report:

1. Target → Issues — select issues to include
2. Right-click → Report selected issues
3. Export as HTML for sharing with the development team

Each issue in the report includes the request/response evidence, severity, and remediation guidance.

Related:

• Burp Suite beginner's guide
• Burp Suite scanner tutorial
• Burp Intruder fuzzing
• Burp Suite vs OWASP ZAP

For ongoing API functional monitoring (not security testing), HelpMeTest runs continuous API tests with plain-English scenarios and alerts on failures.