How to Read Bug Bounty Program Rules
Bug bounty programs reward security researchers for finding vulnerabilities, but the payout depends on following the rules exactly.
Learning how to read bug bounty program rules helps you avoid out-of-scope testing, reduce duplicate reports, and submit findings that are easier for triage teams to validate.
Most programs publish their expectations in a mix of scope lists, severity guidance, safe harbor language, and reporting requirements.
The challenge is not just reading the page, but understanding how the pieces fit together before you start testing.
Start with the scope, not the payout
The scope section is the most important part of any bug bounty policy.
It defines which assets you may test, which are excluded, and sometimes which actions are strictly prohibited even on in-scope targets.
- In-scope assets: Domains, subdomains, mobile apps, APIs, cloud services, or repositories that the program explicitly allows you to test.
- Out-of-scope assets: Anything not listed, including third-party services, staging environments, or internal systems unless specifically included.
- Scoped testing limits: Rules may restrict automation, account creation, rate limits, denial-of-service testing, or social engineering.
If the program uses wildcard entries such as *.example.com, read the exclusions carefully.
A wildcard does not always include every subdomain, and it may omit customer-managed instances, legacy hosts, or assets owned by subsidiaries.
Read the scope table line by line
Many platforms such as HackerOne, Bugcrowd, and Intigriti present scope in tables.
These tables often include the asset, asset type, status, and notes.
Each column matters.
- Asset: Confirms the exact hostname, app package, IP range, or repository name.
- Asset type: Tells you whether the item is a web app, API, Android app, iOS app, or source code repository.
- Status: Shows whether testing is allowed, paused, or informational only.
- Notes: Often contain the real exceptions, such as “authentication required,” “no automated scanning,” or “report only direct impact.”
When notes and the general policy seem to conflict, the more specific rule usually takes precedence.
If the program says “all injection testing allowed” but the notes exclude production endpoints, trust the exclusion.
Understand the prohibited actions
Most researchers lose eligibility not because they find a weak point, but because they violate a program restriction while testing it.
This section usually lists the fastest ways to get a report rejected.
Common prohibited actions
- Denial-of-service attacks or stress testing without permission
- Phishing, impersonation, or social engineering
- Physical attacks or hardware tampering
- Data exfiltration beyond what is needed to prove impact
- Accessing or modifying other users’ data
- Using stolen credentials or leaked secrets from unrelated sources
Some programs allow limited proof-of-concept validation but still forbid destructive actions.
For example, you may be able to demonstrate an IDOR with a single record access, but not download an entire dataset.
The rule is often about minimizing impact, not avoiding verification altogether.
Check severity and payout guidance
Severity guidance explains how the program classifies impact, and payout guidance shows which issues are eligible for rewards.
These two sections are related but not identical.
Severity frameworks may reference the Common Vulnerability Scoring System (CVSS), OWASP risk categories, or program-specific labels such as Low, Medium, High, and Critical.
Payout tables may only reward certain classes of findings, such as remote code execution, privilege escalation, account takeover, or sensitive data exposure.
Before testing, confirm whether the program rewards:
- Purely informational findings
- Misconfigurations with no direct impact
- Low-severity issues like clickjacking or missing headers
- Chained vulnerabilities that require multiple steps
Some mature programs pay only for clearly exploitable issues with concrete security impact.
Others reward unusual logic flaws or authentication bypasses even if they do not fit standard vulnerability categories.
Look for safe harbor and authorization language
Safe harbor language is the program’s formal statement that authorized testing will not be treated as malicious activity if you stay within the rules.
This section matters because it clarifies legal protections, reporting expectations, and escalation paths.
Good safe harbor language usually says the company will not pursue legal action for good-faith research conducted in accordance with the policy.
It may also instruct you to stop testing if you encounter sensitive data and to report the issue promptly.
Even with safe harbor, your protection depends on compliance.
If you test assets outside scope or use disruptive techniques, the protection may no longer apply.
Pay attention to reporting requirements
A strong technical finding can still be rejected if the report does not meet the program’s format.
Reporting requirements usually cover what evidence to include, how fast to submit, and where to send it.
- Reproduction steps: Clear, minimal steps that let triage verify the issue.
- Impact explanation: Why the issue matters to the business or users.
- Evidence: Screenshots, request/response pairs, logs, or short videos.
- Environment details: Browser version, app version, endpoint, account role, and timestamps.
Programs often prefer concise reports with enough detail to reproduce the bug quickly.
Avoid speculative language and avoid overstating impact.
If you cannot prove a claim, describe exactly what you observed instead.
Identify edge cases and ambiguous wording
Bug bounty rules are often written for large, fast-moving environments, so ambiguity is common.
When a rule seems unclear, look for patterns across the policy rather than relying on a single sentence.
Watch for phrases like “best effort,” “reasonable testing,” “no abuse,” and “material impact.” These terms can be subjective, so the safest approach is to test minimally and document carefully.
If the program has a public FAQ, disclosure policy, or researcher forum, use it to clarify interpretation before deeper testing.
Questions to ask yourself before testing
- Is the asset clearly listed as in scope?
- Does the test method violate any restricted activity?
- Can I prove the issue with minimal impact?
- Does the program require prior approval for automation or scanning?
- Is the report likely to be reproducible by the triage team?
Compare the program policy with the platform rules
Many bug bounty programs live on a platform such as HackerOne or Bugcrowd, but the company policy can be stricter than the platform defaults.
Always read both layers.
The platform may provide general rules for acceptable research behavior, while the company adds asset-specific exceptions, special handling instructions, or disclosure timelines.
If there is a conflict, follow the company’s program policy for that target.
This is especially important for:
- Third-party hosted assets
- Acquired brands and legacy infrastructure
- Mobile apps with API backends not fully listed in scope
- Programs that separate production, staging, and beta environments
Use a repeatable reading process
A consistent process makes it easier to evaluate any new bug bounty program quickly.
Experienced researchers often use the same checklist every time before starting tests.
- Read the summary to understand the program’s goals.
- Review the scope table and note exclusions.
- Check prohibited actions and testing restrictions.
- Study payout and severity guidance.
- Read safe harbor and legal language.
- Confirm reporting format and response expectations.
- Look for FAQs, changelogs, or recent policy updates.
This process reduces mistakes and helps you prioritize tests that are both permitted and likely to be rewarded.
Why careful rule reading improves your results
Knowing how to read bug bounty program rules helps you spend time on vulnerabilities the program actually wants.
It also reduces rejection risk, improves triage speed, and builds trust with security teams.
Researchers who understand the policy can focus on high-value assets, keep proofs of concept narrow, and communicate impact in terms the organization can act on.
In practice, that means fewer wasted hours and better chances of earning a valid reward.