1. Introduction

REST APIs are the nervous system of modern applications: they connect frontends to backends, microservices to each other, and enable mobile devices to access data in real time. But if a poorly protected database can be compromised with SQL injection, a poorly designed API can expose the entire infrastructure with a single payload.

In this article we will perform a complete security lab on a REST API using Burp Suite, the de facto standard tool for web pentesting. We will cover everything from endpoint discovery to exploiting common vulnerabilities: IDOR, missing rate limiting, parameter injection, and authentication errors.

2. What is a REST API and why is it a priority target?

A REST API (Representational State Transfer) exposes resources through URLs and standard HTTP methods (GET, POST, PUT, DELETE). Each resource is identified by an endpoint like /api/v1/users/42, and data is exchanged in JSON format.

Unlike a traditional web application where HTML is generated on the server, APIs return raw data that any client (browser, mobile app, script) can consume. This means that an attacker does not need a browser to exploit the API: HTTP requests are enough.

In 2026, according to the OWASP Top 10 for APIs reports, insecure identification vulnerabilities (API4) and mass assignment errors (API8) are the most frequent. Burp Suite is the tool that detects all of them.

3. Setting up the scenario

We will use a local environment with an example REST API built in Python (Flask), accessible at http://localhost:5000. You can also use any public test API like JSONPlaceholder.

Install Burp Suite Community (free) or Professional. Configure the proxy at 127.0.0.1:8080 and set your browser to use that proxy.

# Example API with Flask
from flask import Flask, jsonify, request

app = Flask(__name__)

# Simulated database
USERS = {
    "1": {"id": 1, "email": "ana@company.com", "role": "admin", "balance": 320.50},
    "2": {"id": 2, "email": "luis@company.com", "role": "user", "balance": 12.00},
}

@app.route('/api/v1/users', methods=['GET'])
def get_users():
    return jsonify(list(USERS.values()))

@app.route('/api/v1/users/<id>', methods=['GET'])
def get_user(id):
    user = USERS.get(id)
    if not user:
        return jsonify({"error": "User not found"}), 404
    return jsonify(user)

@app.route('/api/v1/users', methods=['POST'])
def create_user():
    data = request.json
    new_id = str(len(USERS) + 1)
    USERS[new_id] = {"id": int(new_id), **data}
    return jsonify(USERS[new_id]), 201

if __name__ == '__main__':
    app.run(port=5000)

Fig. 1 – Example REST API with GET and POST endpoints for user management.

4. Endpoint discovery

The first step is to map the attack surface. In Burp Suite, open Target → Site Map and navigate through the API using the proxy browser or the Repeater tool.

4.1. Manual exploration with Repeater

We send GET requests to known endpoints:

GET /api/v1/users HTTP/1.1
Host: localhost:5000
Accept: application/json

# Expected response: list of all users
[{"id": 1, "email": "ana@company.com", "role": "admin", "balance": 320.50}, ...]

Then we try different IDs to check for IDOR (Insecure Direct Object Reference):

GET /api/v1/users/1 HTTP/1.1
Host: localhost:5000

# Returns admin data

GET /api/v1/users/2 HTTP/1.1
Host: localhost:5000

# Returns normal user data — is there a difference in the response?

If the /users/<id> endpoint returns all fields (including role) for any ID, we have an IDOR vulnerability: a normal user can see if they are admin or not.

4.2. Parameter fuzzing with Intruder

We use Intruder to test extreme values in IDs:

Payload positions: /api/v1/users/§0§
Payloads: 0, -1, 999999, abc, NULL, '', --

If the API returns data for /users/-1 or /users/abc, it may be suffering from parameter injection. If it returns a 500 error with stack trace, we have additional information about the implementation.

5. Exploitation: common vulnerabilities

5.1. IDOR — Unauthorized resource access

The attacker changes the ID in the URL to access other users’ data:

# User "ana" (admin) logs in and gets JWT token
# Then queries their own profile:
GET /api/v1/users/1 HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

# Now changes the ID to see another user:
GET /api/v1/users/2 HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

# Response: {"id": 2, "email": "luis@company.com", "role": "user", "balance": 12.00}

Defense: validate that the authenticated user has permission to access the requested resource (ownership check).

5.2. Missing rate limiting

Without request limits, an attacker can brute force credentials or exfiltrate data:

# Burp Intruder with 1000 attempts in seconds
POST /api/v1/login HTTP/1.1
Content-Type: application/json

{"email": "admin@company.com", "password": "§0§"}

# Payloads: list of common passwords (rockyou.txt)

Defense: implement rate limiting per IP and per user, with 429 Too Many Requests responses.

5.3. Injection in JSON parameters

When creating a new user, we send additional data that the API does not filter:

POST /api/v1/users HTTP/1.1
Content-Type: application/json

{
  "email": "test@company.com",
  "password": "pass123",
  "role": "user"
}

# Now add an extra field:
{
  "email": "hacker@company.com",
  "password": "pass123",
  "role": "admin"
}

# If the API does not filter the "role" field, we create an admin.

Defense: use whitelists of accepted fields in the backend.

5.4. Mass assignment error

Similar to injection above, but with hidden fields like is_verified, balance, or created_at:

{
  "email": "hacker@company.com",
  "password": "pass123",
  "balance": 9999.99,
  "is_verified": true
}

Defense: explicitly map request fields to database columns.

6. Analysis with Burp Suite Professional (optional)

If we have the Professional version, we can automate analysis:

• Crawler: automatically navigates all endpoints and builds a complete map.
• Automated Scan: detects common vulnerabilities (SQLi, XSS, IDOR) without manual intervention.
• BApp Store: extensions like “AuthMatrix” for permission testing or “Autorize” for automatic IDOR detection.

Fig. 2 – Automated Scan results panel showing detected vulnerabilities.

7. Conclusions

REST APIs are the most exposed entry point in modern applications, and Burp Suite is the essential tool for evaluating their security. The four vectors we have covered — IDOR, missing rate limiting, JSON injection, and mass assignment — represent the majority of real-world vulnerabilities found in production.

The correct defense combines: strict input validation (whitelist), ownership checks for IDOR, configurable rate limiting, robust authentication with JWT or OAuth2, and continuous automated testing. At Jaymon Security we help organizations protect their APIs from design to production.

8. References

• OWASP API Security Top 10 (2023)
• Burp Suite Documentation
• JSONPlaceholder — REST API Testing Resource
• Rapid7: API Security Best Practices 2026

Need help with REST API Security Testing with Burp Suite?

At Jaymon Security, we help organizations protect their systems. From security audits to SIEM/SOC implementation, our expert team designs custom solutions.

Contact us for a free infrastructure assessment.