Multi-step profiles

Add a confirmation step and decide which result should produce an issue.

Build a sequence with the step buttons at the top of Pro's Active Profile editor. Each step has its own request, payload, matching and issue settings. A later step runs when the preceding step matches.

Add and configure steps

1. Open an active profile with Add or Edit and configure Step 1.

2. Click + (Add new step). The editor adds the next numbered step.

3. Select the new step and configure its request, payloads, insertion points, Response and Issue tabs.

4. For later steps, choose Same insertion point than the previous request or Any insertion point as appropriate.

5. Use Reuse Cookie only when the workflow needs cookies from the previous response.

6. Switch between the step buttons to review the sequence.

7. Click OK to save the complete profile. Pro creates the step array in the .bb file automatically.

The - button removes the current step; the profile keeps at least one step. Switching steps preserves the current editor values in memory, but OK is still required to save the file.

Reporting

For an intermediate step, open Issue and check Don't show this issue alert. On the confirmation step, leave it unchecked and enter the final issue title, severity, confidence and explanatory text.

Do not report a confirmed vulnerability merely because the preliminary request produced an interesting response.

Example: probe and confirmation

For a controlled fixture whose original query is ?id=1:

Step	Original Request settings	Response conditions	Reporting
1	Param url value; Append a quote (')	A specific database diagnostic	Suppress the intermediate alert
2	Same insertion point; Replace with the known valid value 1	A marker specific to the normal item response; add an AND NOT condition for the diagnostic if appropriate	Report a tentative indicator

Use the actual diagnostic and normal-response marker from your fixture. A generic success page is not a reliable control. The second step tests a known valid value; it does not reuse the already quoted request wholesale.

Editing the supplied control

The downloadable multi-step example is another preconfigured probe/control profile. Its control uses an enabled empty payload in the saved file. The current editor omits blank payload rows when saving, so verify or redesign that control in the editor before saving a modified copy. Do not assume a blank table row preserves the imported control.

Cookie, insertion and engine differences

Same insertion point keeps the selected location; Any insertion point permits the next step's applicable points and can increase work. With Server's $BBOUNTY$ mode, every step stays on the selected span even when the profile says Any insertion point.

Pro's Reuse Cookie can carry returned cookies to later steps. Server currently reads that setting without executing the same reuse. Neither is a full browser session: redirects, CSRF values and application state need deliberate design.

Raw requests, method conversion and match/replace are incompatible with Server's exclusive marker mode. See compatibility before distributing the saved file.

Validate the whole sequence

Test a positive sequence, failure at each intermediate step, and negative controls. Confirm intermediate steps do not report and the final finding has the expected request/response chain. Reopen the saved file in Pro and review every step. Conditional execution means total requests are not simply payload count multiplied by step count.