Reading Bug Bounty Scopes and Rules

Program scope defines exactly what assets are authorized for testing. In-scope typically lists specific domains, subdomains, IP ranges, or mobile app package names. Testing anything outside scope — even if related — is unauthorized and potentially illegal.

Wildcard scope (*.example.com) includes all subdomains. Explicit lists name specific domains (api.example.com, app.example.com). Some programs use ASN-based scope covering all IPs in a company's autonomous system number — the broadest authorization possible.

Common out-of-scope items: third-party services the company uses (Salesforce, Zendesk), recently acquired companies not yet security-reviewed, specific subdomains with legacy tech, and certain vulnerability types (DoS, brute force, rate limiting without demonstrable impact).

Safe harbor protects good-faith security researchers from legal action when they comply with program rules. Read safe harbor language carefully — it typically requires responsible disclosure, avoiding data access beyond what demonstrates the vulnerability, and no public disclosure before fix.

Most programs prohibit: automated scanning at high rates (DoS risk), testing on production systems that store real user data without explicit permission, social engineering employees, physical security testing, and accessing user accounts without consent.

Bug bounty programs use severity tiers (critical, high, medium, low) to determine rewards. HackerOne and Bugcrowd use Vulnerability Rating Taxonomies (VRT) to classify bugs consistently. Understand how your target program scores vulnerabilities before investing research time.

Before testing, read the full policy including: duplicates policy (first reporter gets credit), safe harbor terms, disclosure timeline, communication expectations, and any specific testing guidance like test accounts or staging environments provided.

Private programs are invite-only — often less competitive and higher signal-to-noise. Public programs are open to all — more competition but more diverse targets. Build reputation on public programs to receive private program invitations with higher rewards.

Coordinated Vulnerability Disclosure (CVD) sets a timeline — typically 90 days — for the vendor to fix before public disclosure. Respect the timeline. If the vendor is unresponsive, contact the program platform. Premature public disclosure harms users and relationships with programs.

When scope is ambiguous, ask via the program's submission questions before testing. "All main product functionality" might or might not include admin panels. Clarifying in advance prevents wasted effort and potential scope violations.

Choose programs aligned with your skills: web app testing skills map to REST API programs, mobile experience to app-specific programs, network expertise to infrastructure bounties. Read recent disclosed reports to understand what the program rewards vs. dismisses as low-impact.

What is the purpose of a safe harbor clause in a bug bounty program?

Understanding bug bounty scope — in-scope assets, prohibited activities, safe harbor terms, reward structures, and disclosure timelines — is essential before testing begins. Reading programs carefully prevents scope violations, wasted effort, and legal risk.