What does bug bounty scope mean?
Bug bounty scope defines the systems a researcher may test and the conditions attached to that authorization. A program may include web domains, wildcard hosts, mobile applications, APIs, network ranges, hardware, source repositories, or other products. It may also exclude particular hosts, actions, vulnerability classes, or environments. Scope is more than a target list: it is the boundary that makes security testing authorized and keeps research focused on systems the program is prepared to receive.
Read the program policy before testing and treat explicit exclusions as first-class data. A target that appears technically related to a company is not automatically permitted. Program status, platform updates, reward eligibility, safe-harbor language, and maximum accepted severity can change how an asset should be handled. Top Scope keeps these details attached to each program so a copied hostname does not become detached from the rule that governs it.
Bug bounty scope examples by asset type
A normalized scope catalog makes different target formats understandable without pretending they are equivalent. The examples below show common representations; the program’s current policy always decides whether a real target is authorized.
*.example.comWildcardAll eligible subdomains under the stated domain, subject to policy exclusions.
api.example.comSubdomainA specific API host that can be tested within the published rules.
com.example.androidMobileAn Android application package or mobile target.
github.com/example/projectSourceA named repository or source-code target, not every repository owned by the organization.
203.0.113.0/24CIDRA defined network range that should be handled according to the program policy.
For bug bounty scope GitHub records, store the exact organization, repository, or source location named by the program. For bug bounty scope Android records, capture the package identifier or official listing instead of relying only on the display name. This precision prevents similarly named projects and applications from being treated as authorized by accident.
A safer scope-management workflow
- 1. Record the source.
Save the program name, platform, policy URL, status, rewards, and tags before importing targets.
- 2. Normalize every asset.
Classify the value, mark its scope state, record eligibility, and add any target-specific notes.
- 3. Filter before testing.
Build a focused in-scope view for the program and asset type needed for the current research task.
- 4. Export with intent.
Use TXT for a unique target list, CSV for program context, or JSON for complete structured records and automation.
- 5. Re-check the policy.
Confirm that the live program page still authorizes the planned testing before sending traffic or attempting exploitation.
Keep the finding connected to the target
Once research produces a vulnerability, the report should retain the affected program and target. The Scope records severity, summary, steps to reproduce, impact, recommendation, weakness, external identifiers, reward details, and status beside that relationship. Personal notes can hold unfinished hypotheses, while the user-isolated vault stores temporary credentials. Shared report changes from analysts and viewers enter administrator review, preserving collaboration without giving every account direct mutation authority.
No tool replaces careful policy review, but a well-structured catalog reduces avoidable mistakes. Top Scope makes it easier to see the boundary, export the right targets, document the evidence, and explain exactly where a finding occurred.