How to Read a Bug Bounty Program’s Scope and Rules

Before you run a single tool against a target, you need to know what you are allowed to test. Every program publishes this as its bug bounty scope and rules, and reading them properly is the most underrated skill in bug bounty. It decides which assets you can touch, which bugs will be paid, and which actions can get you banned from a program. In this post I’ll walk you through how I read a program page, section by section, so you spend your time on bugs that count.

Why the bug bounty scope matters so much

A program page is a contract between you and the company. When you follow it, you are an authorised researcher. When you step outside it, you are testing systems without permission, and no “but I found a real bug” will fix that.

Scope also protects your time. Many beginners report a valid issue on an asset that was clearly marked out of scope and get a “Not Applicable” result. That hurts your signal on the platform and teaches you nothing. Ten minutes of careful reading saves days of wasted work.

If you are new to the recon side of hunting, read why recon matters in bug bounty hunting first. Scope is where every recon session starts.

The parts of a program page

Platforms like HackerOne, Bugcrowd, Intigriti and YesWeHack lay out their pages differently, but almost every program has the same building blocks:

• In-scope assets: the domains, wildcards, apps, APIs or source code you may test.
• Out-of-scope assets: things you must not touch, even if they look related.
• Out-of-scope vulnerability types: bug classes the program will not pay for.
• Rules of engagement: how you are allowed to test (rate limits, test accounts, headers to send).
• Rewards and severity: the payout table and how severity is decided.
• Safe harbour and disclosure policy: the legal protection and when you may talk about a finding.

Read all of them, in that order, before you open your terminal.

Reading in-scope assets correctly

Exact domains vs wildcards

An entry like app.example.com means that one host only. An entry like *.example.com is a wildcard: in most programs it covers subdomains of example.com, and that is where wide recon such as subdomain enumeration really pays off. Check whether the wildcard includes the root domain itself; some programs list example.com separately.

Asset types

Scope is not only websites. You will see mobile apps (with store links or package names), APIs, desktop clients, source code repositories, and sometimes hardware. Each type often has its own reward table and its own notes. A program may pay well for its main web app and much less for a marketing site.

Owned vs third-party assets

A subdomain that points to a third-party service (a help desk, a status page, a hosted blog) may not belong to the company. Unless the program says otherwise, the third party’s own infrastructure is not yours to test. When in doubt, ask the program through the platform before testing.

Out-of-scope rules you must respect

This is the section most people skim, and it is where most “N/A” reports come from. Common exclusions include:

• Specific hosts, such as corporate sites, legacy systems or acquisitions that are still being integrated.
• Denial of service and load testing of any kind.
• Social engineering, phishing of staff, and physical testing.
• Low-impact issues: missing security headers, clickjacking on pages with no sensitive action, self-XSS, logout CSRF, SPF/DMARC records, version banners.
• Findings from automated scanners without a working, demonstrated impact.
• Issues that need an already compromised device or account.

Make a short note of these for each program. When you find something, check it against this list before you write a report.

Rules of engagement: how you are allowed to test

Even inside scope, there are limits on how you test. Look for:

1. Rate limits. Many programs give a requests-per-second limit. Configure your tools to stay under it. In ffuf you can use -rate; in httpx, -rl; in nuclei, -rl as well.
2. Identification headers. Some programs ask you to add a header such as X-Bug-Bounty: yourusername to every request, so they can tell your traffic apart.
3. Test accounts. Use only accounts you created, or the test accounts the program provides. Never access or change another real user’s data. If you find a way to reach someone else’s data, stop at the minimum needed to prove it.
4. Data handling. If you come across personal data, don’t download, keep or share it. Note what you saw and report it.
5. Special instructions. Payment flows may need test cards; some features are testable only on staging hosts.

Here is a simple way to bake a rate limit and a program header into your tools:

# httpx: 10 requests per second, with the program's header
httpx -l hosts.txt -rl 10 -H "X-Bug-Bounty: yourusername" -silent

# ffuf: same idea for content discovery
ffuf -u https://app.example.com/FUZZ -w words.txt -rate 10 -H "X-Bug-Bounty: yourusername"

Rewards, severity and duplicates

The rewards table tells you what the program values. If critical bugs on the main app pay ten times more than anything on secondary sites, plan your time around that.

Check which severity framework they use (often CVSS, or the Bugcrowd VRT). Read their examples: some programs rate the same bug class differently depending on the data involved.

Also read the duplicate policy. Usually only the first valid report is rewarded. Programs with a public “known issues” list are telling you exactly what not to report again.

Safe harbour and disclosure

A safe harbour statement says the company will not take legal action against good-faith research that follows the rules. It is your protection, and it only works if you stay within the scope and rules. Programs without any safe harbour language deserve extra caution.

The disclosure policy tells you whether and when you may publish a write-up. Many programs need explicit permission. Never post details of an unfixed bug, and never share a finding with anyone outside the platform.

Common mistakes when reading scope

• Assuming related means in scope. A domain with the company’s name in it is not automatically theirs, and not automatically in scope.
• Reading once and forgetting. Programs update scope. Re-read the page before each new session and check the change log if the platform shows one.
• Ignoring the excluded bug list. Your report may be valid but still not rewardable.
• Running heavy scans without limits. Fast scans can break things and get your IP blocked or your account removed.
• Testing on real users. Always use your own accounts.

A quick scope checklist

Before each new program, I write a short note with these answers:

1. Which assets are in scope, and are there wildcards?
2. What is explicitly out of scope (assets and bug types)?
3. What rate limit and headers must I use?
4. Which accounts can I test with?
5. Where do the biggest rewards sit?
6. Is there safe harbour, and what is the disclosure rule?

Keep this note next to your recon data. The guide to small, medium and large scope recon shows how the size of a scope changes your whole approach.

Conclusion

Reading the bug bounty scope is not paperwork. It is the first step of good recon and the thing that keeps your work legal, focused and rewarded. Spend ten minutes on the program page, write your checklist, and set your tools to respect the rules before you start.

If you want a structured recon process that starts from scope, the Small Scope Reconnaissance ebook is a good place to begin, and you can learn it live with me in the live bug bounty classes.