Burp extensibility in 2026 shows how testing workflows are evolving

At a glance

What this is: This is PortSwigger’s recap of Burp Extensibility Month, showing how extensions, Bambdas, BChecks, and AI-assisted tooling are being used to automate testing and restore visibility into difficult application scenarios.

Why it matters: It matters because security teams need repeatable ways to test access control, token handling, and unusual request flows, especially where manual testing cannot keep up with application complexity.

By the numbers:

• More than 200 nominations were submitted for 46 extensions.
• 18 votes.
• 17 votes.
• 16 votes.

👉 Read PortSwigger's recap of Burp Extensibility Month and extension awards

Context

Burp Extensibility Month is a good example of how application security tooling now depends on custom workflows rather than a fixed scanner alone. In practice, teams extend Burp when they need better visibility into request manipulation, access control testing, token handling, or specialist application behaviour that standard checks do not expose.

The article also sits at the intersection of application security and identity governance because several highlighted workflows deal with authentication headers, JWTs, CSRF values, short-lived tokens, and access control testing. That makes it relevant to IAM and PAM teams that work with application-layer enforcement, even though the subject is not identity governance in the narrow sense.

Key questions

Q: How should security teams use Burp extensions in application testing workflows?

A: Use them to automate repeated testing tasks, restore visibility into complex request flows, and extend scanner coverage where built-in checks fall short. The best fit is not every test, but the places where token handling, role changes, and custom logic create blind spots that manual testing cannot cover efficiently.

Q: Why do access-control flaws keep showing up in web application testing?

A: Because authentication success does not guarantee correct authorisation, and many applications still enforce privileges inconsistently at the server layer. Testing tools that can replay requests across users, manipulate tokens, and expose hidden endpoints make those mismatches easier to find before attackers do.

Q: What do security teams get wrong about AI safety testing?

A: The common mistake is treating AI safety testing as if it were just another security scan. It is not. Safety testing is about proving how a model or agent fails under pressure, while traditional security tooling is about who can access the system. Those are different governance questions and need different evidence.

Q: How can organisations govern community-built testing extensions safely?

A: Treat them like any other operational tool that can touch sensitive traffic. Review code provenance, restrict where it can run, and test how it handles tokens, headers, and data before allowing it into shared workflows or production-adjacent environments.

Technical breakdown

Why Burp extensibility matters for modern application testing

Burp extensibility spans three mechanisms: extensions, Bambdas, and custom scan checks. Extensions add new capabilities or integrate outside logic, Bambdas let testers write compact inline transformations, and BChecks extend scanner logic with targeted checks. The practical value is not novelty but control over test fidelity. When an application uses unusual request formats, chained authentication, or nonstandard flows, a test harness can restore observability and let the scanner operate against realistic inputs instead of simplified assumptions.

Practical implication: Treat extensibility as a way to preserve test coverage when application behaviour falls outside built-in scanner assumptions.

How AI changes payload generation and extension development

The article shows two different AI patterns. First, AI models are used inside Intruder to generate context-aware payloads for testing prompts, guardrails, and application responses. Second, code agents are used to accelerate extension development, but only when paired with a real Burp execution loop that compiles, runs, and validates the output. The important detail is that AI is not the control plane; the harness is. Without execution feedback, generated code or payloads remain speculative.

Practical implication: Use AI to accelerate testing and development, but keep a deterministic validation loop around every generated change.

Why custom access-control testing still needs human judgement

Several award-winning extensions focus on discovery, token manipulation, and access-control analysis because the hardest failures often appear only when requests are replayed with different roles, values, or timing. Tools such as JWT decoders, auth analyzers, and regex-based token swapper workflows help reduce friction, but they do not decide whether access is appropriate. That judgement still depends on understanding application semantics, role boundaries, and what the server actually enforces at runtime.

Practical implication: Combine automated request manipulation with manual interpretation of privilege boundaries and server-side enforcement.

NHI Mgmt Group analysis

Programmable testing is becoming a core security capability, not a specialist convenience. The article shows that teams are using extensions and custom checks to solve problems that scanners miss, especially around authentication state, token reuse, and complex request logic. That matters because application security programmes increasingly need repeatable test orchestration, not just higher scan volume. The practical conclusion is that extensibility should be treated as part of the testing architecture.

AI-assisted testing introduces a new governance question: who validates the generated behaviour? The most useful AI pattern described here is not raw generation but generation plus runtime verification. That model maps closely to broader AI governance problems, where output quality depends on an execution or review loop rather than model confidence alone. For practitioners, the question is whether AI output can be deterministically tested before it reaches production workflows.

Access-control flaws remain a persistent testing target because server-side enforcement is still uneven. The nominations highlight JWT handling, auth analyzers, token swapping, and specialized discovery because these are the places where hidden endpoints and privilege mismatches surface. In identity terms, this is where application-layer enforcement intersects with IAM assumptions about authenticated users and roles. The practical conclusion is to test the enforcement point, not just the login flow.

Custom tooling is now part of attack simulation as well as defense validation. Extensions that make signed APIs, anti-replay mechanisms, and complex request flows easier to manipulate also show where control design can be brittle. That does not mean the tools are risky in themselves. It means security teams need governance over how testing extensions are built, shared, and used, especially when they touch sensitive tokens or AI-assisted payload generation. The practical conclusion is to manage extensibility as an operational control surface.

What this signals

Extensibility is becoming a control-plane issue for security teams. Once testers rely on extensions, Bambdas, and custom checks to cover real-world application behaviour, the governance question shifts from whether the tool works to how the organisation controls custom logic. That includes review, provenance, and repeatability, especially where the workflow touches authentication data or AI-generated content.

Identity risk often hides in the testing layer before it appears in production. The article’s emphasis on JWTs, access-control analysis, and token swapping shows how auth failures are still easiest to expose when requests are actively manipulated. Teams that want better assurance should align application testing with identity controls such as least privilege, session integrity, and role enforcement, using the OWASP Non-Human Identity Top 10 where NHI-like credentials or tokens are involved.

For practitioners

• Map high-value extension use cases Identify which recurring tasks in your testing workflow justify custom extensions, Bambdas, or BChecks. Prioritise access-control testing, token rewriting, endpoint discovery, and nonstandard request handling where manual repetition creates blind spots.
• Add a deterministic validation loop Require every AI-generated payload, rule, or extension change to run through a real execution harness before use. Validate compile success, runtime behaviour, false positives, and output stability against known test cases.
• Standardise token and header manipulation workflows Document how testers should handle JWTs, CSRF values, authentication headers, and short-lived tokens so that request replay is consistent across tools and testers. Use the same patterns in Burp to reduce drift between manual and automated testing.
• Govern shared testing extensions Review any community or internally built extensions before broad use, especially if they process secrets, access tokens, or live production traffic. Define provenance, review ownership, and update expectations for shared tooling.

Key takeaways

• Burp Extensibility Month shows that custom testing workflows are now part of serious application security practice.
• AI can accelerate payload generation and extension development, but only deterministic validation makes those outputs trustworthy.
• Access-control testing remains one of the clearest areas where extensibility, identity controls, and runtime verification intersect.

Key terms

• Burp Extensibility: The ability to extend Burp Suite with custom logic that changes how testing works. In practice, this includes extensions, Bambdas, and BChecks that automate tasks, add checks, or adapt Burp to unusual application behaviour.
• BCheck: A custom scanner check written to extend Burp’s built-in testing logic. BChecks are used when teams need targeted validation for specific behaviours, edge cases, or application patterns that generic scanning rules do not cover well.
• Bambda: A small Burp script used to automate a narrow transformation or decision in the testing workflow. Bambdas are useful when a tester needs lightweight, repeatable logic without building a full extension.
• Access-control testing: The practice of checking whether authenticated users can perform only the actions they are allowed to perform. In web security, this means testing role boundaries, token handling, and server-side enforcement rather than assuming the login layer is enough.

What's in the full article

PortSwigger's full post covers the operational detail this analysis intentionally leaves for the source:

• Walkthroughs of the award-winning extensions and the specific testing problems they solve in Burp.
• Session-level detail on how AI-assisted payload generation and extension development were demonstrated in practice.
• Examples of custom extension logic used to restore testability in encrypted or otherwise complex application scenarios.
• Community workflow guidance for submitting, sharing, and iterating on extensions, BChecks, and Bambdas.

👉 PortSwigger's full post covers the talks, award winners, and extension workflows in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and machine identity security. It helps practitioners connect identity controls to the wider security workflows their programmes depend on.