For the complete documentation index, see llms.txt. This page is also available as Markdown.

Quick start

Go from a captured request to a finding you can inspect.

1. Pick a representative request

Capture a request to your test application with working authentication. In Profiles → Active Profiles, enable a small relevant set and check its tags.

2. Choose a scanner and a budget

Right-click the request in Proxy, Repeater or the site map. Choose Burp Bounty Pro → Local Scanner → Active Scan → your tag, then review the URL filter.

A starting point: Concurrency 5, Requests per second 10. Concurrency limits simultaneous requests; RPS limits their start rate. Neither guarantees a particular scan duration.

3. Follow the scan and inspect the evidence

Start the scan and follow Scanners → Active and the Dashboard. Open each reported issue and compare the payload, response and matched evidence.

Try a different workflow

Choose Local Scanner → Passive Scan, then the request/response category and tag. Response checks need a captured response. Results appear in Scanners → Passive and matching findings are also registered as Burp issues. A passive check does not send attack payloads.

  1. Wait for Healthy.

  2. Choose Burp Bounty Server Scanner → Active Scan or Passive Scan.

  3. Select a server or all eligible servers, set the budget scope and start.

Pro sends the chosen profiles with the scan. A server-side profile catalogue is needed for MCP name/tag discovery, not for these extension uploads.

Before increasing coverage

Confirm that the expected insertion point was mutated, authentication still works, and the signal distinguishes a positive case from a control. Increase the profile set and request budget gradually. A status of Finished means processing ended; it is not proof that every vulnerability class had the prerequisites it needed.

Keep exploring

Last updated