Burp Bounty Pro provides granular control over scan execution, including pause/resume functionality, per-scan configurable thread pools, request rate limiting, and automatic optimization features.
๐ฎ Dashboard Controls
The Dashboard tab provides the following control buttons:
Button
Action
โธ๏ธ Pause All
Pauses all running scan tasks. Threads block at a safe synchronization point and resume exactly where they left off.
โถ๏ธ Resume All
Resumes all paused tasks. All blocked threads wake up and continue scanning without losing state.
โน๏ธ Stop
Stops all scans and clears the task queue. Running tasks are interrupted.
๐๏ธ Clear Issues
Clears the issues table (does not affect Burp Suite's issue list).
๐ Note: Pause/Resume preserves full scan state โ no scan progress is lost. Tasks continue from the exact point where they were paused.
โธ๏ธ Pause & Resume
Burp Bounty Pro implements true, thread-safe pause/resume using a custom PausableThreadPoolExecutor โ a thread pool that suspends execution without destroying threads or losing state.
Each scan creates its own Scheduler wrapping a PausableThreadPoolExecutor
When Pause is activated, the executor sets isPaused = true
Each thread checks isPaused in beforeExecute() โ if paused, the thread blocks on a Condition.await()
When Resume is activated, isPaused is set to false and Condition.signalAll() wakes all blocked threads
โ Threads continue execution from exactly where they paused
โฑ๏ธ Pause Time Tracking
Burp Bounty Pro tracks the total time each scan spends paused. This paused time is subtracted from the scan duration calculation, ensuring accurate scan time reporting in the Dashboard. If you pause a scan for 10 minutes, the reported scan time reflects only the active scanning time.
๐ Individual vs. Global Pause
โธ๏ธ Pause All / Resume All โ Controls all running scans at once from the Dashboard
Each ScanManager instance maintains its own independent pause state via its own Scheduler
โก Per-Scan Scanner Settings
Scanner settings are configured per scan in the URL filter popup that appears before launching each scan. This allows different scans to use different thread counts and request rates.
๐ Configuration Fields
Setting
Description
Default
๐งต Threads
Number of threads in the scan's thread pool. Each scan creates its own independent Scheduler with this many threads.
10
๐ Concurrency
Maximum concurrent connections for the scan. Controls how many HTTP requests can be in-flight simultaneously.
10
๐ Requests per second
Rate limit for the scan. Controls the maximum number of requests sent per second. A value of 10 means one request every 100ms per thread.
10
๐ง How Per-Scan Settings Work
Each scan is independent โ you can run one scan with 20 threads against a robust target and another with 2 threads against a rate-limited target, simultaneously.
๐ Recommended Configurations
Scenario
Threads
Concurrency
RPS
Notes
๐ดโโ ๏ธ Bug Bounty (fast)
20
20
50
Stable targets with no rate limiting
๐ Penetration Test
10
10
10
Balanced speed and stealth
๐ก๏ธ Rate-Limited Target
3
3
2
Avoid triggering WAF or rate limits
๐ฅ Sensitive Production
2
2
1
Minimal impact on live systems
๐ข Internal Network
30
30
100
Fast scanning on internal infrastructure
๐ก Tip: If a target starts returning 429 (Too Many Requests) or dropping connections, reduce the Threads and RPS values. You can also pause the scan, wait a moment, and resume.
๐ง Smart Scan Default Values
When Smart Scan rules trigger active scans automatically (without a manual popup), default values of 10 threads, 10 concurrency, and 10 RPS are used. These are suitable for most scenarios.
๐ฏ Stop-on-First-Match
When a payload matches for a given profile and insertion point, Burp Bounty Pro automatically stops testing remaining payloads for that same combination.
How it works:
A shared AtomicBoolean flag is created per (profile + insertion point) combination
All payloads for that combination are scheduled as parallel tasks
When one task finds a match, it sets the flag to true
Other tasks check the flag before executing and skip if it's already set
Benefits:
โ Prevents duplicate issues for the same vulnerability
โฌ๏ธ Reduces the number of requests sent to the target
โก Improves overall scan speed
Behavior:
โ ๏ธ Due to the parallel nature of scanning, up to 2 issues may occasionally be reported (race condition is benign)
๐ Multi-step profiles have their own stop-on-match logic per step
๐ Collaborator-based profiles ({BC}) are excluded from this optimization since detection is asynchronous
โฑ๏ธ Scan Timeout
Scans are monitored for timeout conditions:
โฑ๏ธ Scan Timeout โ If a scan exceeds the configured time limit (configurable in Options, in minutes), it's marked as "โ Failed"
๐ Graceful Shutdown โ The thread pool supports a 30-minute graceful shutdown timeout
๐ Redirect Loop Protection
To prevent infinite redirect loops:
๐ก๏ธ A maximum of 30 redirects per request chain is enforced