Burp Suite Extensions for API Security

APIs are now the standard interface of modern applications. They expose business rules, identity flows, mobile backends, partner integrations, and internal services.

This also means that testing API security requires more than a generic web scan.

Burp Suite is excellent for manual analysis, but API security testing benefits from repeatable automations: reviewing JWT behavior, validating object-level authorization, detecting mass assignment patterns, and confirming whether rate limits are enforced on the server.

This article describes a safe approach for designing Burp Suite extensions used in authorized API security assessments.

⚠️ Test only your own APIs or those for which you have explicit permission. The examples below are intended for controlled AppSec validation.

Why build custom extensions for Burp?

Generic tools can miss API-specific issues, such as:

1. JWT validation flaws — missing issuer/audience validation, acceptance of expired tokens, or weak claim validation.
2. BOLA / IDOR — objects accessible without proper ownership validation.
3. Mass assignment — unexpected fields accepted in JSON bodies.
4. Rate-limit gaps — controls applied in the interface, but not in the API.
5. Schema drift — real behavior differs from the OpenAPI contract.

A good extension does not replace human analysis. It helps the tester ask the same question consistently across multiple endpoints.

Principle 1: prefer evidence over exploitation

An AppSec extension should safely collect evidence:

• original request;
• category of modification applied;
• response status;
• response size difference;
• relevant header changes;
• timing difference;
• risk hypothesis;
• need for manual confirmation.

Avoid automatically declaring that something is “vulnerable” based on a single HTTP status code. API behavior depends heavily on application context.

Principle 2: keep tests configurable

Every environment is different. A safe extension should allow configuration of:

• maximum request rate;
• allowed hosts;
• test categories;
• custom headers;
• safe payload values;
• excluded endpoints;
• whether active requests are allowed.

This reduces the risk of generating noise or accidental production impact.

Extension idea 1: JWT validation assistant

Instead of building a “JWT attacker,” think in terms of a JWT validation assistant.

What to check

• Is there a bearer token in the request?
• Which algorithm is declared?
• Are claims such as iss, aud, exp, nbf, iat, and kid present?
• Does the token appear to be expired?
• Are sensitive claims exposed to the client?
• Is the same token reused across unrelated scopes?

Safe output

The extension can log findings such as:

• Audience claim missing;
• Issuer claim missing;
• Token lifetime too long;
• Claim that appears to represent a role/permission present;
• Manual validation recommended.

Pseudocode

class AssistenteValidacaoJwt:
    def analisar_requisicao(self, requisicao):
        token = extrair_bearer_token(requisicao)
        if not token:
            return []

        cabecalho, payload = decodificar_sem_verificar(token)
        achados = []

        for claim in ["iss", "aud", "exp"]:
            if claim not in payload:
                achados.append(f"Recommended claim missing: {claim}")

        if "role" in payload or "admin" in payload:
            achados.append("Role claim present; confirm server-side authorization")

        return achados

This is safer than automatically sending forged tokens. If active testing is required, require explicit opt-in and staging scope.

Extension idea 2: mass assignment probe

Mass assignment happens when an API accepts fields that should never be controlled by the client.

Safer testing strategy

Instead of injecting dangerous values, use harmless sentinel fields:

{
  "displayName": "Paulo",
  "__appsec_probe": "mass-assignment-check"
}

Then compare:

• Did the API reject the unexpected field?
• Did the API ignore the field?
• Did the field appear in the response?
• Did the value persist after a confirmation GET?

Recommended evidence

• Endpoint and method.
• Original body format.
• Sentinel field added.
• Response behavior.
• Whether persistence occurred.

Mitigation

• Use DTOs/serializers with an explicit allowlist.
• Reject unknown fields.
• Separate user-controlled fields from server-controlled fields.
• Add tests for sensitive fields such as role, isAdmin, tenantId, credit, price, and discount.

Extension idea 3: helper for BOLA / IDOR

Broken Object Level Authorization is one of the most common risks in APIs.

A Burp extension can help identify candidate IDs and prepare controlled comparisons.

What to detect

• Numeric IDs in the path: /api/accounts/123;
• UUIDs in the path or body;
• Object IDs in JSON fields;
• Tenant IDs;
• User IDs;
• Invoice, order, or document IDs.

Safe workflow

1. The tester provides two authorized test accounts.
2. The extension records requests from account A.
3. The tester provides equivalent objects belonging to account B.
4. The extension prepares comparison requests.
5. The tester manually confirms the behavior.

Avoid blind object guessing. BOLA validation should be structured and authorized.

Extension idea 4: rate limit validator

Rate limiting is often implemented in the frontend, the API gateway, or the identity layer. The extension should answer a narrow question:

Does the server enforce a limit within the approved test rate?

Safe controls

• Low rate by default.
• Hard maximum number of requests.
• Host allowlist.
• Stop when receiving 429.
• Stop on a spike in 5xx responses.
• Clear warning before any active testing.

Useful signals

• First 429 response.
• Rate limit headers.
• Retry-After header.
• Difference between authenticated and unauthenticated limits.
• Whether the limit is per token, IP, account, or global.

Extension idea 5: OpenAPI drift checker

If an OpenAPI schema exists, an extension can compare observed traffic with the expected contract.

Check for:

• undocumented endpoints;
• undocumented methods;
• extra fields in responses;
• missing required fields;
• unexpected content types;
• inconsistent error codes.

This type of analysis often produces useful AppSec findings without requiring aggressive testing.

Secure design checklist for Burp extensions

Before enabling any automation, validate these points:

• Does the project have documented scope and authorization?
• Does the extension have an allowlist of hosts and endpoints?
• Are active tests disabled by default?
• Is there a hard rate and volume limit?
• Does the report distinguish between hypothesis, evidence, and confirmed vulnerability?
• Is there an option to export evidence without secrets, tokens, or personal data?
• Was the workflow validated first in staging or with test accounts?

Report template

For each finding, record:

Title: [API risk hypothesis]
Endpoint: [method + path]
Evidence: [request/response summary]
Impact: [what could go wrong]
Confidence: Low/Medium/High
Manual validation: Required/Completed
Recommendation: [specific fix]

This format keeps automation honest and avoids overstating risk.

Practical implementation notes

If you are creating Burp extensions today, consider:

• using the Montoya API for modern Java/Kotlin extensions;
• using Jython only for legacy workflows;
• keeping active tests disabled by default;
• adding per-project configuration;
• logging enough evidence for reproducibility;
• making all payloads editable.

References and related reading

• PortSwigger Burp Extender API
• PortSwigger Montoya API
• OWASP API Security Project
• WAF Defensive Validation Checklist for AppSec and Blue Team
• HTTP Security Headers
• WAF Bypass in Practice: Real Techniques, Detection, and Mitigation

FAQ

Do Burp Suite extensions replace manual API testing?

No. They reduce repetitive work and standardize evidence, but authorization, business logic, and impact findings require human validation.

Is it safe to automate active testing on production APIs?

Only with authorization, rate limiting, an approved window, monitoring, and a stop condition. The safest default is to start with passive analysis and enable active tests by opt-in.

Which API should be used for new Burp extensions?

For modern projects, prefer the Montoya API in Java or Kotlin. Jython still appears in legacy environments, but it tends to be less suitable for new extensions.

Conclusion

Custom Burp extensions are powerful when they reduce repetitive work and improve the quality of the evidence.

The goal is not to automate exploitation. The goal is to help AppSec teams validate API risks consistently, safely, and with enough context to fix the issues.

Start with passive checks, add controlled active probes, and always design the extension for authorized testing.