APIs are now the default interface for modern applications. They expose business logic, identity flows, mobile backends, partner integrations, admin actions, and internal workflows that were never designed to be tested only through a browser UI.
Burp Suite is excellent for this type of work, but in API-heavy environments the interesting evidence is often scattered across requests, parameters, tokens, JSON fields, status codes, and small behavioral differences.
That is where a safer Burp extension can help: not as an auto-exploit button, but as an evidence assistant that helps the tester identify weak signals, organize findings, and keep the human operator in control.
This post walks through a defensive design approach for Burp Suite extensions focused on API security testing: JWT review, BOLA/IDOR validation, mass assignment checks, rate-limit evidence, and a small local lab reference.
This is intended for authorized security testing, internal AppSec validation, and controlled lab environments. The goal is to improve defensive verification and reporting, not to automate abuse against systems you do not own or have permission to test.
Why API testing needs better evidence
Many API vulnerabilities are not obvious from a single request.
A missing authorization check may only become clear when you compare two users. A mass assignment issue may only matter if a sensitive field is accepted by the backend. A JWT problem may be low risk in one architecture and critical in another. A rate-limit weakness may depend on identity, endpoint, cost of operation, and business impact.
For that reason, API testing usually depends on correlation:
- Which endpoint was called?
- Which identity or role was used?
- Which object ID or tenant boundary was involved?
- What changed between request A and request B?
- Did the server reject the action, ignore the field, or process it?
- Is there enough evidence to justify a finding?
A useful Burp extension should help capture that context instead of only producing generic alerts.
Safer extension design
A security testing extension should avoid aggressive default scanning, destructive state-changing requests without explicit operator action, high-volume brute force behavior, and claims of impact without request/response evidence.
The extension should support the tester, not replace judgment. A good rule of thumb is: passive first, controlled active validation second, clear evidence always.
Passive checks are a good starting point because they reduce risk and noise. The extension observes traffic already passing through Burp and extracts signals that may deserve review.
For JWT review, the extension can decode tokens locally and highlight patterns such as missing aud claims, unexpected iss values, unusually long expiration windows, missing role/scope information, or inconsistent claims between users.
The important point is not to declare vulnerable just because a claim is absent. The better output is a review note:
JWT observed without an aud claim. Validate whether this token can be replayed across services or accepted by unintended APIs.
That gives the tester a hypothesis and a next step.
For JSON APIs, the extension can highlight sensitive fields that often deserve attention: role, isAdmin, permissions, accountType, tenantId, userId, price, discount, status, verified.
Again, the extension should not assume impact. It can mark these fields as interesting and help the tester decide whether a controlled mass assignment validation is appropriate.
APIs also expose patterns that help organize testing:
- /api/users/{id}
- /api/accounts/{accountId}/invoices
- /api/admin/*
- /graphql
- /swagger
- /openapi.json
A Burp extension can group similar endpoints, identify object identifiers, and show where authorization boundaries may need manual review.
Controlled active checks
Active validation is where extensions can become risky if they are too automatic. My preference is to make active checks explicit and controlled.
For BOLA or IDOR testing, the extension can let the tester select two known authorized contexts:
- User A request
- User B request
Then it can help compare whether changing an object identifier or token produces an unexpected authorization result. It should not automatically enumerate IDs.
For mass assignment, instead of injecting a long list of fields, the extension can help the tester build a small allowlist of candidate fields based on what already appeared in the application traffic. The finding is only valid if the backend actually processes the unauthorized field in a meaningful way.
For rate-limit evidence, the extension does not need to flood an endpoint. It can help document whether rate-limit headers exist, whether responses change after a small number of attempts, and whether limits apply per IP, per account, per token, or per endpoint.
A safe local lab reference
To make this more practical, imagine a small local API lab running only on your machine at http://127.0.0.1:5000.
The lab has two demo users and a few intentionally simplified endpoints:
POST /login
GET /api/me
GET /api/users/{userId}/profile
GET /api/users/{userId}/invoices
PATCH /api/users/{userId}/profile
POST /api/password-reset/request
A minimal dataset could look like this:
User A: id 1001, role user, tenant alpha
User B: id 1002, role user, tenant beta
Admin: id 1, role admin, tenant internal
The point of this lab is not to attack a real target. It is to create predictable traffic that lets you design and test the Burp extension behavior safely.
Lab exercise 1: passive JWT review
Log in as User A and User B through Burp and let the extension observe the Authorization bearer tokens.
The extension should decode the JWT locally and create a review card like this:
Token review
Endpoint observed: GET /api/me
Subject: 1001
Role claim: user
Issuer: local-api-lab
Audience: missing
Expiration: 24h
Note: Missing audience claim. In a multi-service architecture, validate whether this token is accepted by unintended APIs.
This gives the tester a concrete question without overstating impact. Missing aud is not automatically a vulnerability, but it is worth reviewing in systems where multiple services trust the same identity provider.
Lab exercise 2: BOLA comparison
Capture two normal requests:
User A -> GET /api/users/1001/invoices
User B -> GET /api/users/1002/invoices
A safe extension workflow would let the tester select both requests and ask: compare object access between these two authorized users.
Then the extension can prepare a controlled validation candidate:
User A token -> GET /api/users/1002/invoices
The important part is that the tester explicitly approves the replay. The extension should not automatically enumerate IDs.
The evidence card might look like this:
Candidate finding: Possible BOLA / IDOR
Original context: User A accessing /api/users/1001/invoices
Validation context: User A token used against /api/users/1002/invoices
Expected result: 403 or 404
Observed result: 200 with invoice metadata
Confidence: Medium
Next step: Validate with another authorized test pair before reporting
That gives you a clean report artifact without turning the extension into an ID enumeration tool.
Lab exercise 3: mass assignment signal
Suppose the lab returns this profile object:
id: 1001
displayName: User A
email: user-a@lab.local
role: user
verified: false
And the normal profile update request only sends displayName.
The extension can mark role and verified as sensitive response-only fields. It should not blindly inject them into every request. A better workflow is to show the candidate fields and ask the tester which one to validate in the local lab.
For a controlled lab test, the tester might choose one harmless candidate: verified true.
The extension should capture whether the backend rejects the field, ignores the field, reflects it only in the response, or persists it after a fresh GET /api/me. The last case is the one that creates meaningful evidence.
A useful output would be:
Mass assignment review
Endpoint: PATCH /api/users/1001/profile
Candidate field: verified
Server behavior: field persisted after follow-up GET /api/me
Impact hypothesis: user-controlled verification state
Recommendation: use server-side allowlists for updateable fields
Lab exercise 4: low-volume rate-limit observation
For rate-limit checks, the lab can expose a non-destructive endpoint: POST /api/password-reset/request.
The extension does not need to send hundreds of requests. In a local lab, three to five controlled attempts are enough to test whether the extension captures useful evidence:
Attempt 1 -> 200 OK
Attempt 2 -> 200 OK
Attempt 3 -> 429 Too Many Requests
Headers -> Retry-After: 60
The extension can then record:
Rate-limit evidence
Endpoint: POST /api/password-reset/request
Attempts observed: 3
Limit signal: HTTP 429 with Retry-After header
Scope still unknown: per account, per IP, per token, or global
Next step: confirm expected policy with the application team
This keeps the test safe and focused. The goal is not to bypass the control. The goal is to document whether the control exists and whether the evidence is clear enough for an AppSec conversation.
Evidence-first reporting
The most valuable part of an extension is often not detection. It is reporting.
A practical API security finding needs enough context for developers and defenders to reproduce, understand, and fix the issue.
For each candidate finding, I like to capture title, endpoint, HTTP method, affected parameter or JSON path, identity/role context, original request reference, validation request reference, observed response difference, impact hypothesis, remediation guidance, and confidence level.
This turns Burp from a request replay tool into a structured evidence workspace.
Final thoughts
Burp Suite extensions can make API security testing faster, but speed is not the only goal. The real value is consistency: finding weak signals, preserving context, reducing false positives, and producing evidence that developers and defenders can act on.
For me, the best extension is not the one that screams critical the most. It is the one that helps a tester ask better questions:
- Is this object access actually authorized?
- Did the backend process a field the client should not control?
- Is this token accepted where it should not be?
- Is there enough evidence to write a fair finding?
That is the direction I think safer API security tooling should take: less magic, more context, better evidence.
I publish more AppSec and offensive security notes in Portuguese at paulo.seg.br. A related article about Burp Suite extensions for API security is available here: Extensões Burp Suite para Segurança de APIs.
—
Paulo Rigonato is a security practitioner focused on offensive security, AppSec, API testing, AI security, and defensive validation. He publishes technical notes and practical security research at paulo.seg.br.
