Overview
Scope in a bug bounty program defines exactly which assets and activities are authorized. Reading and respecting scope is the most important operational skill in bug bounty. This lesson covers scope.
Learning objectives
- Define scope in the bug bounty context.
- Distinguish in-scope from out-of-scope.
- Explain reading scope carefully.
Core concept
A program's scope lists the in-scope assets (the domains, applications, APIs, or systems you may test) and the out-of-scope ones (explicitly forbidden), along with any constraints on how you may test. Scope is often detailed — it may include specific domains/subdomains, wildcard scopes, mobile apps, or APIs, and it commonly excludes third-party services, certain subdomains, or specific techniques. Reading scope carefully and testing only within it is essential, since scope is the concrete expression of the program's authorization.
How it works
Before testing, the researcher reads the scope precisely: which assets are in-scope (noting exactly what wildcards or patterns cover), which are excluded, and what testing constraints apply. They confirm each target they touch is genuinely in-scope. Scope can be nuanced — a wildcard like *.example.com may be in-scope but with specific exclusions, or only certain asset types may be covered. Misreading scope (testing something not actually covered) is a common, serious mistake. Careful scope reading, and verifying each target against it, keeps testing authorized and focused.
Practical example
A program's scope lists *.example.com as in-scope except legacy.example.com and blog.example.com, and excludes all third-party services. A researcher enumerating subdomains finds several under example.com plus a third-party service. They test the in-scope subdomains but exclude legacy and blog (explicitly out-of-scope) and the third-party service — carefully matching each discovered asset against the scope before testing. This precise scope adherence keeps every action authorized.
Cybersecurity relevance
Scope adherence is the core operational discipline of bug bounty: testing out-of-scope assets is unauthorized (illegal) and a frequent cause of program bans and legal trouble, even when unintentional. Careful scope reading — especially with nuanced wildcard scopes and exclusions — is essential, and researchers must verify each target against the scope. It reflects the scope discipline from the ethical-hacking path applied to bounty programs. Respecting scope protects the researcher, keeps testing legal, and maintains the trust the bug bounty model depends on.
Common mistakes
- Misreading nuanced scope (e.g. wildcard scopes with exclusions), testing something not covered.
- Testing explicitly out-of-scope assets (excluded subdomains, third-party services).
- Not verifying each discovered target against the scope before testing.
Key takeaways
- Scope lists in-scope assets (what you may test) and out-of-scope ones (forbidden), plus testing constraints — the concrete expression of the program's authorization.
- Scope can be nuanced (wildcards with exclusions, specific asset types); read it carefully and verify each target against it before testing.
- Scope adherence is the core operational discipline; testing out-of-scope is unauthorized and a common cause of bans/legal trouble — respect it strictly.
Check your understanding
- Why is carefully reading nuanced scope (like wildcards with exclusions) important in bug bounty?
- What should a researcher do before testing each asset discovered during enumeration?