How to Avoid Out of Scope Testing in Bug Bounty

Updated 15 November 2026 · Standard formula, shown below

This guide explains how to stay within the authorized boundaries of a bug bounty program, so you can focus your effort on what will be rewarded and avoid wasting time or risking your reputation. You’ll learn how to read a program’s scope correctly, set up your testing environment to prevent accidental out-of-scope requests, and handle edge cases like subdomains and API endpoints. By the end, you’ll have a clear process for verifying scope before you start and during your testing.

What You’ll Need

A bug bounty platform account (e.g., HackerOne, Bugcrowd, Intigriti) where the program is hosted.
Access to the program’s policy page or scope definition document.
A web browser with developer tools (Chrome DevTools, Firefox DevTools).
Optional: A proxy tool like Burp Suite or OWASP ZAP for intercepting and modifying requests.
A text editor or note-taking app to record scope boundaries and your testing checklist.

Step-by-Step

Read the entire program policy, not just the scope section. Many programs include scope details in the policy text, such as “all subdomains of example.com” or “only the api.example.com endpoint.” Look for sections labeled “Scope,” “Out of Scope,” “Rules of Engagement,” and “Testing Guidelines.”
Identify the exact assets in scope. The scope may list domains, subdomains, IP ranges, mobile apps, or specific API endpoints. Write them down. For example, if the scope says “*.example.com,” that includes any subdomain, but not example.org or example.net.
Note the out-of-scope list. This often includes third-party services (e.g., payment processors, CDNs), staging environments, or specific subdomains like “old.example.com.” Treat this list as a hard boundary—do not test any of these.
Check for scope changes. Programs can update scope at any time. Before each testing session, revisit the program page and compare the current scope with your notes. Some platforms send notifications on scope changes, but don’t rely on that.
Set up a dedicated testing environment. Use a separate browser profile or a virtual machine for bug bounty testing. This prevents accidental requests to out-of-scope domains from your personal browsing history or extensions. Configure your proxy (if using one) to only intercept traffic to in-scope domains.
Use a scope-checking tool or script. Tools like Burp Suite’s “Scope” settings allow you to define in-scope URLs and will highlight out-of-scope requests. If you’re scripting (e.g., with Bash or Python), include a regex check that matches only in-scope domains before sending any request.
Start with passive reconnaissance. Before sending a single request, gather information about the target from public sources: search engines, certificate transparency logs, DNS records, and the program’s own documentation. This helps you map the attack surface without touching anything.
Test only the in-scope assets. When you find a subdomain or IP that isn’t clearly in scope, do not test it. If you’re unsure whether an asset is in scope, err on the side of caution and skip it. You can always ask the program’s security team for clarification (see Troubleshooting).
Monitor your requests in real time. As you test, keep an eye on your proxy’s traffic log. If you see a request going to an out-of-scope domain (e.g., a third-party API call or a redirect), stop that action immediately. Note the URL and adjust your testing approach.
Respect rate limits and testing windows. Some programs specify maximum requests per second or testing hours. Even if not stated, avoid aggressive scanning that could disrupt the service or trip WAFs, which might lead to your IP being blocked.
Document your testing steps. For each vulnerability you find, record the exact URLs, parameters, and requests you made. This helps you prove that you stayed in scope if there’s ever a dispute.
When you find a vulnerability, re-verify scope. Before writing your report, double-check that the affected asset is still in scope. If the program’s scope changed during your testing, the vulnerability might no longer be eligible for a reward.

Common Mistakes

Assuming a subdomain is in scope because the root domain is. Always read the wildcard syntax. “*.example.com” includes subdomains, but “example.com” alone does not.
Testing the main site when only the API is in scope. Some programs restrict testing to specific endpoints. Sending a payload to the main site could be considered out of scope.
Following redirects to out-of-scope domains. A link on an in-scope site might redirect to a third-party service. If you follow it and test that service, you’ve left scope.
Using automated scanners without configuring scope. Tools like nuclei or sqlmap may crawl and test any URL they find, including out-of-scope ones. Always configure them with a target list or regex.
Ignoring the “Out of Scope” section because it’s long. That section is just as important as the in-scope list. It often includes critical assets that you must not touch.

Tips

Bookmark the program’s scope page and check it at the start of every testing session.
Use a browser extension like “ScopeGuard” or a custom script that blocks requests to out-of-scope domains.
If you use Burp Suite, set the “Target Scope” and enable “Use advanced scope control” to highlight out-of-scope requests in red.
When in doubt, ask the program’s security team via the platform’s message system. They are usually responsive and appreciate that you’re checking.
Keep a checklist of in-scope assets and cross them off as you test each one. This prevents duplicate testing and ensures you don’t stray.
Remember that the program’s rules apply to your tools too. If a tool makes a request to an out-of-scope domain, you’re responsible for that request.

Troubleshooting

You accidentally sent a request to an out-of-scope domain. Stop testing immediately. Note the request details, then review whether it was a one-off or a systematic issue. If it was a redirect, adjust your proxy settings to block out-of-scope hosts. If it was a tool misconfiguration, fix the tool’s scope settings. Do not continue until you’re sure it won’t happen again.
You’re unsure whether a specific asset is in scope. Check the program’s policy for a definition of “asset” or “subdomain.” If it’s still unclear, message the program’s security team and ask. Do not test the asset until you receive a clear answer.
The program’s scope changed after you started testing. Stop testing the assets that were removed from scope. For any vulnerabilities you already found on those assets, check the program’s disclosure policy—some programs still accept reports if the vulnerability was discovered before the scope change, but you must verify.
Your IP got blocked by the WAF. This is not necessarily a scope violation, but it may be a sign of aggressive testing. Wait a while, then reduce your request rate. If you were using a scanner, reconfigure it to be more conservative.
You found a vulnerability on a subdomain that is not listed in scope but appears to be owned by the same company. Do not test it. Even if it’s owned by the same entity, the program’s scope is the contract. Report the subdomain to the program as a potential scope expansion suggestion, but do not test it.

Frequently Asked Questions

What does “out of scope” mean in bug bounty?

Out of scope refers to any asset, domain, or activity that the program has explicitly excluded from testing. Testing these is a violation of the program’s rules and can lead to your report being rejected or even your account being banned.

Can I test a subdomain that is not listed but resolves to the same IP as an in-scope asset?

No. The scope is defined by the program’s text, not by IP ownership. If the subdomain is not explicitly listed or covered by a wildcard, it is out of scope.

What happens if I accidentally test an out-of-scope asset?

You should stop immediately and not report any findings from that asset. If you report a vulnerability found on an out-of-scope asset, the program may reject it and could penalize you. It’s best to be transparent about the mistake if you need to contact the program, but usually it’s better to just move on.

Is it okay to test the mobile app if the scope only lists the website?

No. If the mobile app is not listed in scope, you must not test it. The same applies to APIs, desktop clients, or any other asset.

How do I know if a wildcard like “*.example.com” includes nested subdomains like “a.b.example.com”?

It depends on the program’s definition. Some programs consider “*” to match any subdomain at any depth, while others only match one level. Read the policy carefully; if it’s ambiguous, ask the program.

Can I use a vulnerability scanner that automatically crawls links?

Yes, but you must configure it to only target in-scope domains. Many scanners have a “scope” or “target” setting. If your scanner doesn’t, you should use a proxy that filters out-of-scope requests before they reach the scanner.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.