# Smart Scan

Smart Scan is one of the most powerful features of Burp Bounty Pro. It uses **Rules** to automatically trigger active scanning profiles when specific passive conditions are detected — creating intelligent, context-aware scanning workflows.

## 💡 Concept

Smart Scan follows an **IF-THEN** pattern:

```
IF passive profile(s) match → THEN execute active profile(s)
```

This means:

1. 👁️ **Passive profiles** continuously analyze all traffic (requests and responses)
2. 📋 When a passive profile matches, **rules** check if conditions are met
3. 🎯 If conditions are met, **active profiles** are automatically executed against the matched request

## ❓ Why Smart Scan?

Instead of running all active profiles against every request (which is slow and noisy), Smart Scan:

* ⚡ **Reduces scan time** — Only tests relevant vulnerabilities for each target
* 🎯 **Reduces false positives** — Only scans when context suggests a vulnerability is likely
* 🤖 **Automates workflows** — No manual intervention needed to target specific technologies
* 🖥️ **Enables technology-specific testing** — Detects WordPress, Jira, Spring, etc. and runs their CVE profiles

## ⚙️ How It Works

### 📘 Example: WordPress Detection

1. 👁️ **Passive Response profile** `Wordpress detection` matches responses containing WordPress indicators (e.g., `wp-content`, `wp-includes`)
2. 📋 **Rule** `Wordpress_Rule` is configured:
   * **IF**: Passive Response profile `Wordpress detection` matches
   * **THEN**: Execute active profiles: `Wordpress_user_enum_oembed`, `Wordpress_user_enum_json`, `Wordpress_directory_listing`, `Wordpress_Path_Traversal`, `Wordpress_Config_Accessible`, etc.
3. 🎯 **Active scanning** automatically begins on the matched request with WordPress-specific profiles

### 📘 Example: SQL Injection Parameter Detection

1. 👁️ **Passive Request profile** `SQLi_Parameters` detects parameters like `id=`, `user_id=`, `query=`
2. 📋 **Rule** `SQLi_Rule` is configured:
   * **IF**: Passive Request profile `SQLi_Parameters` matches
   * **THEN**: Execute active profiles: `SQLi`, `SQLi_Timebased_Encoded_Space`
3. 🎯 **Active scanning** targets only the requests with suspicious parameters

## 📋 Rule Structure

Each rule consists of:

### 🔍 Match Conditions (IF)

One or more passive profile matches that must be satisfied:

* 📨 **Passive Request profiles** — Match patterns in HTTP requests
* 📩 **Passive Response profiles** — Match patterns in HTTP responses
* 🔗 **Logic operators** — Combine conditions with AND/OR:
  * **AND** — All conditions must match
  * **OR** — At least one condition must match

### 🎯 Execute Actions (THEN)

What to do when conditions are met:

* 📝 **Execute specific profiles** — Run named active profiles
* 🏷️ **Execute profiles by tag** — Run all active profiles with a specific tag (e.g., all profiles tagged "XSS")
* 🎯 **Match scope** — Execute on "All Matches" or "First Match" only

## 🔄 Smart Scan Flow

```
HTTP Traffic
  │
  ├─ 📨 Passive Request Profile matches request
  │   └─ 📋 Check Rules → IF condition met → 🎯 Execute Active Profiles on this request
  │
  └─ 📩 Passive Response Profile matches response
      └─ 📋 Check Rules → IF condition met → 🎯 Execute Active Profiles on this request
```

## 📊 Smart Scanner Tab

Smart Scan results are displayed in the dedicated **Scanners** > **Smart** sub-tab:

* Lists each evaluated request with host, method, URL, and matched rules
* Shows which active profiles were launched and scan count
* Includes request/response viewers for inspection

## ⚙️ Configuration

### ⚡ Scanner Settings

When Smart Scan rules trigger active scans automatically, they use default scanner settings (**10 threads**, **10 concurrency**, **10 RPS**). These defaults are suitable for most scenarios.

When you manually launch a Smart Scan via the context menu, the URL Filter popup appears with context-aware settings:

| Setting                    | Description                                    |
| -------------------------- | ---------------------------------------------- |
| 🧵 **Threads**             | Number of threads for the scan                 |
| 🔀 **Passive Concurrency** | Maximum concurrent passive profile evaluations |
| 🔀 **Active Concurrency**  | Maximum concurrent active scan connections     |
| 📈 **Requests per second** | Rate limit for the scan                        |

See [Scan Control](/scanning/scan-control.md) for details on per-scan performance configuration.

### ✅ Enabling/Disabling Rules

* Go to **Burp Bounty Pro** > **Rules** tab
* Enable/disable individual rules with the checkbox
* Only enabled rules participate in Smart Scan

## 📦 Default Rules

Burp Bounty Pro ships with 28 pre-configured rules covering:

* 🖥️ **Technology detection** — WordPress, Jira, Spring Boot, Drupal, Symfony, Weblogic, CouchDB, etc.
* 💉 **Vulnerability parameters** — SQLi, XSS, RCE, LFI, SSRF, SSTI, Open Redirect
* 🌐 **Bulk scanning** — Disabled by default: scan all requests with specific profile groups

See [Default Rules](/reference/default-rules.md) for the complete list.

## 📖 Creating Custom Rules

See [Creating Rules](/rules/creating-rules.md) for a step-by-step guide.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.bountysecurity.ai/scanning/smart-scan.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.