Configure Burp Suite Target Scope to Focus Testing (2026)

Burp Suite’s target scope is the most powerful, yet most misunderstood, feature for focused web application security testing.

Let’s see it in action. Imagine you’ve just scanned an application and Burp’s Target tab is overflowing with requests. You only care about the API endpoints for now.

Here’s how you’d start narrowing it down:

Target -> Scope -> Add -> https://api.example.com/v1/

Now, if you navigate to the Proxy -> HTTP history tab, you’ll see a new column appear: Scope. Any request that matches your defined scope will show a green checkmark. If it doesn’t, you’ll see a red 'X'.

This isn’t just about hiding noise; it’s about controlling Burp’s behavior. When you define scope, Burp only actively crawls, scans, and sends requests matching that scope to certain tools. If you send a request to the Repeater that isn’t in scope, Burp will warn you.

The real power comes from understanding how to define scope effectively. You can use:

• URLs: https://www.example.com/admin/ will include everything under /admin/.
• Wildcards: *.example.com will match api.example.com, staging.example.com, etc.
• Regular Expressions: https://[^/]+\.example\.com/user/[0-9]+ will match specific user IDs on any subdomain.

Let’s say you’re testing a complex application with multiple subdomains and paths, but you’re only interested in the user management section of app.example.com.

1. Go to Target -> Scope.
2. Click Add.
3. In the input field, type: https://app.example.com/user/
4. Ensure Include in scope is selected.
5. Click OK.

Now, any request that hits https://app.example.com/user/ and its sub-paths will be marked in scope. If you later realize you need to include a specific static asset directory for analysis, you can add another entry:

1. Click Add again.
2. Type: https://app.example.com/static/
3. Click OK.

Burp will now track both.

What about excluding things? Sometimes you need to include a broad domain but exclude specific sensitive areas or third-party integrations.

1. Click Add.
2. Type: https://app.example.com/
3. Select Include in scope.
4. Click OK.
5. Click Add again.
6. Type: https://app.example.com/third-party/
7. Select Exclude from scope.
8. Click OK.

Now, anything under /third-party/ will be explicitly ignored, even though it falls under the broader https://app.example.com/ inclusion.

The order of scope rules matters. Burp processes them from top to bottom. The first rule that matches a request determines whether it’s included or excluded. This allows for fine-grained control. For instance, you might include https://app.example.com/* and then exclude https://app.example.com/admin/* if you want to analyze everything except the admin panel.

The Target -> Scope tab is also where you can import and export scope configurations. This is invaluable for team collaboration or for saving your scope for repeat engagements. You can also clear the scope entirely if you need to start fresh.

Many users think scope is just for filtering the HTTP history tab. They miss that it directly influences the Spider, Scanner, and even how Burp interacts with tools like Intruder and Repeater when you initiate actions from the Target tab. If a request isn’t in scope, initiating a scan from the Target tab on that request will yield no results, and the spider won’t crawl links from it.

The most subtle aspect of scope is its interaction with Burp’s project settings. When you load a saved project, Burp automatically loads the scope that was active when the project was saved. This means if you’re working on multiple projects, ensure your scope is correctly set for the project you’re currently analyzing, or you might find yourself accidentally analyzing the wrong application.

Understanding and mastering Burp Suite’s target scope is the single most effective way to reduce testing time and increase the signal-to-noise ratio in your security assessments.

The next hurdle is efficiently using the Scanner tool within your defined scope.