Overview
The in-scope assets are the systems a program authorizes you to test. Correctly identifying them is the starting point of any bug bounty engagement. This lesson covers in-scope assets.
Learning objectives
- Define in-scope assets.
- Interpret common in-scope asset specifications.
- Verify targets against the in-scope list.
Core concept
In-scope assets are the specific systems the program permits testing on — listed in the policy as domains, subdomains, wildcard scopes (e.g. *.example.com), applications, APIs, mobile apps, or other systems. They define the authorized attack surface. In-scope specifications vary: some programs list exact domains, others use wildcards (broad but sometimes with exceptions), and some include specific asset types (web, API, mobile). Understanding exactly what the in-scope list covers is essential before testing.
How it works
The researcher reads the in-scope list precisely and maps it to concrete targets. A wildcard scope like *.example.com authorizes subdomains under example.com (subject to any exclusions), so enumeration (later modules) discovers which specific assets that covers. Exact-domain scopes are narrower. The researcher verifies each target they intend to test genuinely falls within the in-scope specification — that a discovered subdomain is actually covered by the wildcard and not excluded, that an asset type is included, etc. This precise mapping ensures testing stays on authorized assets.
Practical example
A program's in-scope list includes *.example.com and the mobile app, but exact-lists only api.example.com for APIs. During enumeration, the researcher finds several subdomains and an API at internal-api.example.com. They test the in-scope subdomains and api.example.com, but treat internal-api.example.com as not in-scope (only api.example.com was listed for APIs) unless the wildcard clearly covers it — verifying against the policy first. Precisely mapping discoveries to the in-scope specification kept testing authorized.
Cybersecurity relevance
Correctly identifying in-scope assets is fundamental to legal, authorized testing: it defines what you may test, and misjudging it (testing something not actually covered) is unauthorized. Wildcard scopes especially require care — they are broad but often qualified by exclusions or asset-type limits. Verifying each discovered target against the in-scope specification before testing prevents accidental out-of-scope testing (a common cause of bans/legal issues). This precise scope mapping is the operational core of authorized bug bounty and feeds directly into recon and asset discovery.
Common mistakes
- Assuming a wildcard covers everything without checking exclusions or asset-type limits.
- Testing discovered assets without verifying they fall within the in-scope specification.
- Confusing asset types (e.g. testing an API not covered by a web-only scope).
Key takeaways
- In-scope assets are the systems the program authorizes for testing (domains, wildcards, apps, APIs, mobile) — the authorized attack surface.
- Specifications vary (exact domains, wildcards with exceptions, asset-type limits); understand exactly what is covered and verify each target against it.
- Precise in-scope mapping keeps testing authorized and prevents accidental out-of-scope testing — the operational core feeding recon and asset discovery.
Check your understanding
- What kinds of specifications define in-scope assets, and why do wildcards require extra care?
- Why must each discovered target be verified against the in-scope list before testing?