Safety Center

How to Read a Bug Bounty Scope Page

The scope page is the law of a bug bounty programme: it says what you may test, what you must not touch, and how to report. This guide teaches you to read one properly, with a worked example from a public programme.

By Abdul Hannan · Published 14 November 2026 · Updated 14 November 2026

Try the tools: Bug Bounty Scope Checker · Vulnerability Report Builder

Why the scope page matters more than any tool

A bug bounty programme is an invitation with boundaries. The company is saying: you may test these things, in these ways, and we will pay or recognise valid findings. Everything outside those boundaries is not an invitation — it is somebody else's system, and testing it without permission is unlawful in many countries even if you report the bug afterwards. Practitioner guides put it in one sentence: the scope page is the law of that programme. No page in this cluster teaches how to read one, which is why this guide exists.

The anatomy of a scope page

Programme summary: what the programme covers, who runs it, and where to report. Read it first; it often states the programme's philosophy — for example, whether it welcomes beginners or focuses on severe findings.
In-scope assets: the domains, subdomains, applications, APIs and sometimes mobile apps you may test. These are usually listed precisely — for example, a specific domain and its subdomains, or a named application. Only these are authorised.
Out-of-scope assets: the things explicitly excluded — often staging environments, third-party services, marketing sites, or assets belonging to a subsidiary. If it is listed here, do not test it.
Allowed and forbidden techniques: which testing methods are permitted and which are not. Denial-of-service testing, social engineering, and automated scanning are commonly forbidden; some programmes forbid specific tools or rate limits.
Rewards and severity: how the programme rates findings and what it pays or recognises for each level. These tables change, and the programme's own severity judgement is final.
Reporting rules: where and how to report, what a report must include, the disclosure policy (usually private first, with a coordinated window before any public disclosure), and the rules on duplicate reports.
Safe harbour and legal language: many programmes state that in-scope testing done in good faith will not lead to legal action. Read the exact wording — safe harbour covers in-scope activity only, and it does not override the law.

Worked example: a public vulnerability disclosure programme

Consider a typical public programme run by a large technology company — the kind listed on HackerOne or Bugcrowd with a public scope page. Its in-scope list names a main domain and a set of subdomains, plus a named mobile app. Its out-of-scope list excludes the company's marketing site, its status page, and any third-party service it uses. Its forbidden techniques include denial-of-service testing, phishing employees, and testing the physical offices. Its disclosure policy requires private reporting and forbids public disclosure before a fix.

Now imagine you are hunting in this programme. You find a weakness in the main domain's login flow — in scope, and a valid target. While testing you notice the same weakness in the marketing site — out of scope, so you stop: you do not test it further, and you may mention its existence in your report and let the owner decide. You are tempted to test whether the weakness also affects the mobile app — the app is listed as in scope, so you may test it, but only within the allowed techniques and only on your own account. You consider sending a phishing email to an employee to test awareness — forbidden, so you do not. At each step, the scope page, not your curiosity, decides.

That discipline is the skill. The hunters who get invited to private programmes are not the ones who found the most weaknesses; they are the ones with a history of clean, in-scope reports. Programme owners remember who stayed inside the lines.

Reading technique: a checklist for every scope page

Read the whole page, top to bottom, before testing anything. Skimming the asset list and skipping the rules is how hunters get banned.
Write down the in-scope assets in your own notes, with the date. Note any asset that looks in scope but has a condition attached.
Write down the out-of-scope list and the forbidden techniques, and keep them visible while you test.
Check the disclosure and duplicate rules: how long to wait, what counts as a duplicate, and whether public disclosure is allowed at all.
Check the reward table's date. Old blog posts about a programme's payouts are not the current rules — the scope page is.
If anything is ambiguous, ask the programme owner through the platform before testing. A question costs a day; an unauthorised test can cost your account and more.

Common scope mistakes

Testing a subdomain that is not listed. The most common error. Subdomains are only in scope when the page says so.
Assuming an asset is in scope because it looks similar to one that is listed. Similarity is not authorisation.
Running automated scanners when the programme forbids them, or running them at a rate that degrades service.
Testing third-party services the target uses — a payment provider, a support platform — unless the scope explicitly includes them. It almost never does.
Reporting a finding publicly before the programme's disclosure window, or disclosing a finding the programme asked you to keep private.
Continuing to test after finding something out of scope. Stop, report what you already observed, and let the owner decide.

After the scope: the report

Once you have a finding inside scope, the report is the product. Use the structure in our vulnerability report template: title, asset, steps to reproduce, evidence, impact explained honestly, and suggested fix. State the scope you relied on and the date you read it — that line protects you and helps the triage team. Then wait: triage takes time, duplicates happen, and a polite, patient hunter gets better outcomes than an impatient one.

For the full legal-first path that this guide fits into, read Bug Bounty for Beginners and Security Research for Beginners.

Sources

Last checked: 14 November 2026

Frequently asked questions

What is a bug bounty scope page?

It is the programme's official rules page. It lists the assets you are authorised to test, what is out of scope, which techniques are allowed or forbidden, how to report, and what rewards or recognition apply.

What does in scope mean in bug bounty hunting?

In scope means the asset or technique is covered by the programme's authorisation: you may test it, and valid findings may earn a reward. Anything not listed as in scope should be treated as out of scope.

What is usually out of scope in a bug bounty programme?

Common exclusions include denial-of-service testing, social engineering and phishing of staff, physical attacks, testing third-party services, and automated scanning that degrades service. Each programme lists its own exclusions — read them, do not assume them.

Can I test something that belongs to the same company but is not listed?

No. Authorisation covers only the listed assets. Testing an unlisted asset — even one owned by the same company — is unauthorised, and reporting afterwards does not make it lawful.

What should I do if a scope page is unclear?

Ask the programme owner through the platform before testing. Do not test first and ask later — the test itself is the act that needs authorisation.

How often do scope pages change?

Regularly. Programmes add and remove assets, change reward tables and update rules. Always re-read the scope on the day you test, and keep a dated copy of the version you relied on.