🔍Match Types

Match types define how Burp Bounty Pro determines whether a vulnerability was found. The MatchType field controls the logic used to evaluate grep patterns and other detection conditions.

📝 Grep-Based Match Types

✅ MatchType 1: All Conditions (AND)

All grep patterns must match for the issue to be reported.

{
  "MatchType": 1,
  "Grep": [
    "true,,Simple String,Only in Headers,Access-Control-Allow-Credentials: true",
    "true,OR,Simple String,Only in Headers,Access-Control-Allow-Origin: https://evil.com"
  ]
}

📝 Note: Even though individual patterns use OR operators between them, MatchType 1 requires the combined result to be true. The OR operators define groups that are evaluated, then all groups must pass.

🔀 MatchType 2: At Least One (OR)

At least one grep pattern must match for the issue to be reported.

{
  "MatchType": 2,
  "Grep": [
    "true,,Regex,,Location:\\shttp://{REDIRECT_DOMAIN}",
    "true,OR,Regex,,location\\.replace\\(.http://{REDIRECT_DOMAIN}",
    "true,OR,Regex,,http-equiv=\"refresh\" content=\".*url=.http://{REDIRECT_DOMAIN}"
  ]
}

📋 Grep Pattern Types

📝 Simple String

Searches for an exact substring in the response.

true,,Simple String,,error_message

• 🔤 Case sensitivity controlled by CaseSensitive field

• ⚡ Fastest match type

🔣 Regex

Searches using a regular expression pattern.

true,,Regex,,(?i)password\s*[:=]\s*['"][^'"]+['"]

• 📚 Supports full Java regex syntax

• 🎯 More flexible but slower than Simple String

• 🔤 Use (?i) flag for case-insensitive regex, or set CaseSensitive: false

📊 Grep Pattern Format

Each grep entry follows this format:

enabled,operator,type,scope,pattern

Component	Description	Values
enabled	Whether this pattern is active	true, false
operator	Logic operator (empty for first pattern)	(empty), AND, OR
type	Pattern matching method	Simple String, Regex
scope	Where to search	(empty = all), Only in Headers, Only in Body
pattern	The search string or regex	Any string

⚙️ Operator Logic

Grep patterns are grouped by operators and evaluated with short-circuit optimization:

Pattern1 AND Pattern2 OR Pattern3 AND Pattern4

Evaluates as:

(Pattern1 AND Pattern2) OR (Pattern3 AND Pattern4)

• ✅ AND groups are evaluated left to right; if any pattern fails, the group fails

• 🔀 OR connects groups; if any group passes, the result is true

🎯 Response Scope

Control where in the response patterns are searched:

Scope	Description
(empty)	🌐 Search the entire response (headers + body)
Only in Headers	📋 Search only in HTTP response headers
Only in Body	📄 Search only in the response body

⚡ Special Match Types

🪞 Payload Reflection (MatchType 3)

Checks if the exact payload appears in the response.

{
  "MatchType": 3,
  "PayloadResponse": true
}

The scanner sends the payload and checks if the response contains the unmodified payload string. Useful for reflected XSS detection.

🪞 Payload Reflection Without Encoding (MatchType 4)

Like MatchType 3, but checks for the payload before any encoding was applied.

{
  "MatchType": 4,
  "PayloadResponse": true
}

⏱️ Timeout (MatchType 5)

Detects time-based vulnerabilities by measuring response time.

{
  "MatchType": 5,
  "isTime": true,
  "TimeOut1": "5000",
  "TimeOut2": "10000"
}

Comparison modes:

• 📊 Between — Response time is between TimeOut1 and TimeOut2 (milliseconds)

• ⬆️ Greater than — Response time exceeds TimeOut1

• ⬇️ Less than — Response time is below TimeOut1

Use cases:

• 🗄️ Time-based SQL injection (e.g., SLEEP(5))

• ⚡ Time-based blind command injection

• 🖥️ Server-side processing delays

📏 Content Length (MatchType 6)

Detects vulnerabilities by comparing response content length differences.

{
  "MatchType": 6,
  "iscontentLength": true,
  "contentLength": "100"
}

The scanner:

1. 📡 Sends a baseline request (without payload)

2. 💉 Sends the payload request

3. 📊 Compares content lengths

4. 🐛 If the difference exceeds the threshold, reports an issue

Use cases:

• 🗄️ Boolean-based SQL injection

• 🔓 Access control bypasses (different response sizes)

📊 Variations (MatchType 7)

Detects changes in specific response attributes between baseline and payload requests.

{
  "MatchType": 7,
  "VariationAttributes": [
    "status_code",
    "content_type",
    "content_length",
    "tag_count"
  ]
}

The scanner compares the specified attributes between the baseline response and the payload response. If any attributes differ, it reports an issue.

📊 Invariations (MatchType 8)

The opposite of Variations — detects when response attributes remain the same when they should differ.

{
  "MatchType": 8,
  "VariationAttributes": [
    "content_length"
  ]
}

🔢 HTTP Response Code (MatchType 9)

Matches specific HTTP status codes in the response.

{
  "MatchType": 9,
  "IsResponseCode": true,
  "ResponseCode": "200"
}

Use cases:

• 📂 Path discovery (200 vs 404)

• 🔓 Authentication bypass (200 vs 401/403)

• ⚠️ Server errors (500)

🌐 Collaborator-Based Detection

For out-of-band vulnerability detection using Burp Collaborator:

1. 🔧 Use {BC} variable in payloads to generate a Collaborator subdomain

2. 🔄 The scanner periodically polls Burp Collaborator for interactions

3. ✅ If an interaction is detected, the vulnerability is confirmed

{
  "Payloads": [
    "true,http://{BC}/test"
  ]
}

Collaborator detection is asynchronous — results may appear after the scan completes. The polling interval is configurable in Options (collaboratorRefreshtime).

⚠️ Note: Collaborator-based profiles are excluded from the stop-on-first-match optimization since detection happens asynchronously.

🔄 Negative Matching

Set NotResponse: true to invert the match logic — the issue is reported when the pattern is NOT found:

{
  "NotResponse": true,
  "Grep": [
    "true,,Simple String,Only in Headers,Strict-Transport-Security"
  ]
}

This reports an issue when the Strict-Transport-Security header is missing. Commonly used for security header checks in Passive Response profiles.