# 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.


---

# 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/rules/creating-rules.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.