# Creating Rules

This guide walks you through creating Smart Scan rules step by step.

## 1️⃣ Step 1: Open the Rule Editor

1. Go to **Burp Bounty Pro** > **Rules** tab
2. Click **Add** to create a new rule
3. 🪟 The rule editor dialog opens

## 2️⃣ Step 2: Basic Information

| Field              | Description                | Example                                 |
| ------------------ | -------------------------- | --------------------------------------- |
| 📝 **Rule Name**   | Unique identifier          | `My_Custom_Rule`                        |
| ✅ **Enabled**      | Whether the rule is active | `true`                                  |
| 📄 **Description** | What the rule does         | `Detect Spring Boot and test actuators` |

## 3️⃣ Step 3: Define Match Conditions (IF)

Add one or more passive profile conditions that must be met before the rule triggers.

### ➕ Adding a Condition

1. Select the condition type:
   * 📨 **Passive Request** — Match against HTTP requests
   * 📩 **Passive Response** — Match against HTTP responses
2. Select the passive profile to reference
3. Set the logic operator (for the second condition onward):
   * ✅ **AND** — Both this condition and the previous must match
   * 🔀 **OR** — Either this condition or the previous must match

### 📚 Condition Examples

**🔍 Single condition:**

```
IF Passive Response profile "Wordpress detection" matches
```

**✅ Multiple AND conditions:**

```
IF Passive Request profile "Fortinet_Request" matches
AND Passive Response profile "Fortinet_Panel" matches
```

**🔀 Multiple OR conditions:**

```
IF Passive Request profile "CouchDB_Request" matches
OR Passive Response profile "CouchDB_Response" matches
```

### ⚙️ Logic Evaluation

When combining AND and OR:

```
Condition1 AND Condition2 OR Condition3
```

This evaluates as:

```
(Condition1 AND Condition2) OR Condition3
```

✅ AND has higher precedence than OR.

## 4️⃣ Step 4: Define Execute Actions (THEN)

### 📝 Execute Specific Profiles

Run one or more named active profiles:

```
THEN execute:
  - Profile "CVE-2021-44228_RCE_Log4j"
  - Profile "CVE-2021-44228_RCE_Log4j_GETPOST"
  - Profile "CVE-2021-44228_RCE_Log4j_urlEncode"
```

### 🏷️ Execute by Tag

Run all active profiles that have a specific tag:

```
THEN execute all profiles with tag "XSS"
```

This is more maintainable than listing individual profiles — when you add new XSS profiles and tag them, they're automatically included in the rule.

### 🎯 Match Scope

Choose how many times the action executes:

| Scope               | Behavior                                                     |
| ------------------- | ------------------------------------------------------------ |
| 🔄 **All Matches**  | Execute for every match of the passive condition             |
| 1️⃣ **First Match** | Execute only for the first match (avoids redundant scanning) |

**All Matches** is the default and recommended for most cases. Use **First Match** when:

* 🔄 The passive profile matches frequently and you only need one test
* ⬇️ You want to reduce scan load on the target
* 🖥️ The vulnerability check only needs to run once per host

## 5️⃣ Step 5: Save the Rule

💾 Click **Save** to store the rule. It becomes immediately active if `Enabled` is set to `true`.

## 💡 Tips for Effective Rules

### 🖥️ Use Technology Detection as Triggers

Create passive profiles that detect specific technologies, then trigger targeted CVE profiles:

```
IF detect WordPress → THEN run WordPress CVE profiles
IF detect Jira → THEN run Jira CVE profiles
IF detect Spring Boot → THEN run Spring Boot Actuator profiles
```

### 💉 Use Parameter Detection for Vulnerability Classes

Create passive profiles that detect interesting parameters, then trigger the appropriate vulnerability profiles:

```
IF detect SQLi-like parameters → THEN run SQLi profiles
IF detect redirect/URL parameters → THEN run Open Redirect + SSRF profiles
IF detect file/path parameters → THEN run LFI/Path Traversal profiles
```

### 🔗 Combine Request and Response Conditions

For more precise targeting, require both request and response conditions:

```
IF request matches "Fortinet_Request" (URL pattern)
AND response matches "Fortinet_Panel" (page content)
THEN execute CVE-2018-13379_FortiOS_Creds_Disclosure
```

This avoids false triggers from URL patterns alone.

### 📦 Start with Default Rules

Review the 27 default rules for patterns and inspiration. Most common scenarios are already covered.

### 🏷️ Tag-Based Rules for Broad Scanning

Use tag-based execution for flexible, broad rules:

```
IF detect any request → THEN execute tag "Open Redirect"
```

> ⚠️ **Warning:** Broad rules like these can generate a lot of traffic. Only enable them when needed and consider using "First Match" scope.