Building Safer Burp Suite Extensions for API Security Testing

⋅


APIs are now the default interface for modern applications. They expose business logic, identity flows, mobile backends, partner integrations and internal services.

That also means API testing often requires more than a generic web scan.

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

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

⚠️ Only test APIs you own or have explicit permission to assess. The examples below are intended for controlled AppSec validation.

Why Build Custom Burp Extensions?

Out-of-the-box tooling may miss API-specific issues such as:

  1. JWT validation weaknesses — missing issuer/audience checks, expired token acceptance, weak claim validation.
  2. BOLA / IDOR patterns — object IDs accepted without ownership validation.
  3. Mass assignment — unexpected fields accepted in JSON bodies.
  4. Rate limit gaps — controls enforced in the UI but not on the API.
  5. Schema drift — behavior differs from the OpenAPI contract.

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

Design Principle 1: Prefer Evidence Over Exploitation

An AppSec extension should collect evidence safely:

  • original request;
  • modified request category;
  • response status;
  • response length difference;
  • relevant header changes;
  • timing difference;
  • risk hypothesis;
  • manual confirmation needed.

Avoid automatically declaring “vulnerable” from a single response code. API behavior often depends on application context.

Design Principle 2: Keep Tests Configurable

Every environment is different. A safe extension should allow the tester to configure:

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

This prevents accidental noisy testing in production.

Extension Idea 1: JWT Validation Assistant

Instead of a “JWT attacker”, build a JWT validation assistant.

What It Should Check

  • Is a bearer token present?
  • Which algorithm is declared?
  • Are iss, aud, exp, nbf, iat and kid present?
  • Does the token look expired?
  • Are sensitive claims present client-side?
  • Is the token reused across unrelated scopes?

Safe Output

The extension can report findings such as:

  • Missing audience claim
  • Missing issuer claim
  • Long token lifetime
  • Token contains role-like claim
  • Manual validation recommended

Pseudocode

class JwtValidationAssistant:
    def analyze_request(self, request):
        token = extract_bearer_token(request)
        if not token:
            return []

        header, payload = decode_without_verifying(token)
        findings = []

        for claim in ["iss", "aud", "exp"]:
            if claim not in payload:
                findings.append(f"Missing recommended claim: {claim}")

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

        return findings

This is safer than automatically sending forged tokens. If active tests are needed, require explicit opt-in and a staging scope.

Extension Idea 2: Mass Assignment Probe

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

Safer Test 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 it ignore the field?
  • Did the field appear in the response?
  • Did the value persist after a follow-up GET?

Recommended Evidence

  • Endpoint and method.
  • Original body shape.
  • Added sentinel field.
  • Response behavior.
  • Whether persistence was observed.

Mitigation

  • Use DTOs / serializers with explicit allowlists.
  • 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: BOLA / IDOR Helper

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

A Burp extension can help by identifying candidate object IDs and preparing controlled comparisons.

What to Detect

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

Safe Workflow

  1. Tester provides two authorized test accounts.
  2. Extension records requests from account A.
  3. Tester supplies equivalent objects owned by account B.
  4. Extension prepares comparison requests.
  5. Tester manually confirms behavior.

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

Extension Idea 4: Rate Limit Validator

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

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

Safe Controls

  • Default low request rate.
  • Hard maximum request count.
  • Per-host allowlist.
  • Stop on 429.
  • Stop on 5xx spike.
  • Clear warning before active test.

Useful Signals

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

Extension Idea 5: OpenAPI Drift Checker

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

Check for:

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

This often produces high-value AppSec findings without aggressive testing.

Reporting Template

For each finding, report:

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 Build Notes

If you are building Burp extensions today, consider:

  • Montoya API for modern Java/Kotlin extensions.
  • Jython only for legacy Burp extension workflows.
  • Keeping active tests disabled by default.
  • Adding project-level configuration.
  • Logging enough evidence for reproducibility.
  • Making all payloads editable.

Final Thoughts

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

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 them.

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

I publish more AppSec and pentest notes at paulo.seg.br. A related Portuguese version of this topic can be expanded into a full tutorial for the blog.

Liked Liked