Profile-driven DAST: passive rules and stateful active checks

[xhzeem]

Proposal

Make Nuclei DAST a stronger standalone, profile-driven web-application testing engine, using GBounty as an example of reusable active/passive checks and multi-step scanning. This is about Nuclei DAST itself; it does not require Burp, a Burp extension, or a Burp-specific integration.

What Nuclei already provides

• -dast templates for active fuzzing, including request-part fuzzing.
• -dast-server, which accepts a URL and raw HTTP request and queues it for DAST fuzzing.
• Nuclei workflows and authentication/configuration building blocks.

The request is to build on those capabilities, not replace them. In particular, a DAST server that accepts a request for active fuzzing is not by itself a live passive scanner or a stateful profile runner.

Desired capabilities

1. Reusable check profiles — group active and passive checks with names, tags/categories, payload sets, insertion-point selectors, matchers/extractors, and per-check safety settings. Keep profiles declarative and compatible with Nuclei templates where practical. Distinguish vulnerability-check profiles from scan/configuration profiles.
2. Live passive analysis — accept complete request/response exchanges and run passive checks without sending additional attack requests. The current DAST server input is request-shaped; passive analysis of live exchanges needs response data too.
3. Conditional active checks — allow a passive match or other rule to trigger a selected active profile against the relevant host, endpoint, and same parameter/insertion point, rather than spraying every check at every captured request.
4. Stateful, multi-step checks — support baseline → mutation → confirmation sequences that retain cookies/session state, extract and reuse CSRF or other tokens, and keep follow-up tests tied to the original injection point. Useful confirmation signals include response differences, timing, error behavior, and out-of-band interactions.
5. Operational controls and evidence — scope boundaries, request budgets/rate limits, deduplication, cancellation/resume, and findings with the triggering profile plus relevant request/response evidence.

Use case

A user submits or streams real application traffic to Nuclei DAST. Passive profiles inspect each exchange. Rules select relevant active profiles; those profiles perform controlled, state-aware follow-up requests and report evidence. The same profiles should also be runnable from the CLI against supplied requests/targets for repeatable automation.

Non-goals

• Recreating a commercial GUI or requiring a third-party proxy product.
• Removing the existing template DSL or breaking current CLI/template workflows.
• Unbounded fuzzing: active checks must respect explicit scope and request/rate budgets.

Related work checked

• #4953 proposed proxy-server input and live fuzzing; it was closed after the DAST server API work. The API is useful groundwork but is not the complete profile/rule/stateful workflow described here.
• #6153 proposed a passive server mode; it was closed as stale, not implemented.
• #5927 proposed follow-up requests and comparisons tied to the same fuzz point; it was closed as stale.
• #4793 tracks more complete authenticated-target support and remains open.
• #5567 concerns scan/template configuration profiles; those are distinct from reusable vulnerability-check profiles proposed here.

Acceptance criteria

• A passive check can evaluate a supplied request/response exchange without issuing a new target request.
• A configurable rule can trigger a chosen active profile from a passive match.
• A multi-step profile can preserve/update cookies or extracted tokens and run a confirmation request against the same selected insertion point.
• CLI and server/API execution produce equivalent findings with bounded, inspectable request/response evidence and enforceable scope/rate limits.