Bug Bounty: How to Read Program Scope Properly

1 hour ago

2 min read

Scope pages are legal-ish poetry. One missed bullet about 'subsidiaries excluded' can invalidate a week of work.

I read scope three times: once for assets, once for prohibitions, once for reporting rules. Highlights go on a sticky note above my monitor.

Scope mistakes are expensive—treat the policy like a contract clause, not a suggestion, because platforms enforce it like one.

In-scope vs reachable

A wildcard doesn't mean every port and every acquisition forever. Check dates, regions, and mobile app bundle IDs separately.

Third-party SaaS embedded in the app may be out even when the iframe loads on-scope.

Social engineering bans, user data handling, rate limit testing caps, and duplicate lookup expectations.

Ask in the program channel before testing edge cases. 'Is api.staging.example.com included?' beats guessing.

Scope discipline protects users and your account standing.

If it's not listed and not clarified, assume out-of-scope until told otherwise.

When programs update scope, diff the page—silent expansions are gifts if you notice before others.

Small habits compound—what feels like overhead early becomes speed when deadlines hit.

Scope attachments often live separate from the main policy—check for PDFs on mobile deep links, SDKs, and cloud tenants.

Wildcard inclusions may exclude certain vulnerability classes even when the host matches—read the fine print on SSRF and post-exploitation.

Note safe harbor clauses and their conditions—some require headers or contact emails before testing.

Third-party bug bounty platforms may add rules atop vendor policy—both apply.

Save HTML snapshots of scope pages; silent edits happen before big events.

Bug Bounty: Choosing Programs as a Beginner

Scope Discovery for Web Pentests: WHOIS, ASN, and Certificates

A Practical Bug Bounty and Pentest Methodology