Bug Bounty Scope Parsing: How to Test the Right Assets
The first bug in a bounty session can happen before you send a request: you misread the scope. A wildcard looked broader than it was, a mobile API lived on a third-party domain, or the program allowed a hostname but excluded the feature you tested. Good scope reading is not paperwork. It is how you protect users, your account, and the report you hope to get paid for.
Copy the scope into a working note before recon. For each entry, record the literal asset, asset type, allowed testing, exclusions, reward eligibility, and date last checked. Keep “in scope” separate from “bounty eligible.” Programs sometimes accept reports for a property while paying only for listed assets.
Read wildcards literally
*.example.com usually covers subdomains such as api.example.com, but not automatically the apex example.com. It does not prove that example.net, a cloud bucket, an IP address, or a newly acquired brand is included. A wildcard defines a name pattern, not corporate ownership.
Watch for depth rules. A policy may intend all subdomains, while a platform's asset entry matches only one label. If a.b.example.com matters, check the written policy and ask rather than betting on an interpretation. Port scope matters too: a hostname entry may cover all services on that host, or the rules may limit testing to HTTPS.
Mobile apps complicate the map. The package can be in scope while its backend domains are not listed, or the API may be in scope but testing the production mobile client is restricted. Browser extensions, thick clients, source maps, and smart-device endpoints need the same asset-type check.
Build an exclusion overlay
Global exclusions override the asset list. Mark rules about denial of service, social engineering, physical access, automated scanning, credential attacks, third-party services, customer data, and destructive testing. Then mark vulnerability classes the program will not accept: self-XSS, missing headers, clickjacking, rate limits, or theoretical issues without impact.
Read safe-harbor language and account requirements. Some programs require a researcher header, a specific email alias, test-account naming, or an IP submitted in advance. Others ban accessing any data beyond your own even when an authorization bug is suspected. Those instructions shape the proof you collect.
Third-party boundaries deserve care. A support widget on an in-scope page may belong to Zendesk; a payment form may belong to Stripe; DNS may point at a managed SaaS tenant. The surrounding page does not grant permission to test the provider. Focus on the target's configuration and integration unless the third-party asset is explicitly listed.
Resolve ambiguity before exploitation
Recon can reveal an old hostname that clearly carries the company's branding but appears nowhere in scope. Passive validation is one thing; exploitation is another. Capture ownership evidence, send the program a short question, and wait. A day spent clarifying beats a suspension.
Scope changes. Recheck the live page before a deeper test and save a timestamped copy or screenshot of the rules. Do not rely on a cached search result or a six-month-old community post. If an asset disappears while you are working, pause and contact the program.
Make triage's job easy
In each report, name the exact scoped asset and quote the rule that authorizes the test when the boundary is not obvious. Explain why a discovered host belongs to that asset family. If you stayed within two owned accounts, say so. If sensitive data appeared unexpectedly, state that you stopped immediately and did not retain it.
My practical rule is simple: when reasonable people could read the scope two ways, do not choose the interpretation that grants you more access. Ask. Strong hunters are not measured by how close they can get to the edge of authorization; they are measured by whether their evidence is useful, reproducible, and safely obtained.