Labs · Cyber Security

Lab: Read a Real Bug Bounty Programme's Policy and Scope Page and List What Is In and Out of Scope

By Ravindra Bagale Last updated: 8 October 2026

Beginner30 minBrowser · Notes or spreadsheet · HackerOne or Bugcrowd public programme directory

Course: Cyber Security · Chapter 35: Careers, Certifications and Bug Bounty

Chapter 35 covers careers, certifications and bug bounty; this lab practises the most important bug bounty skill: reading the rules before touching anything.

Chala mitrano! In bug bounty, the scope page is the law. Testing one domain that is out of scope can mean a ban, or even police trouble, even if you meant well. Professionals read the rules first, slowly. Today we only read, no testing at all, and we make a clean summary. Niyam aadhi, kaam nantar!

Suppose we are…

Suppose we want to start bug bounty on weekends, alongside a job at Accenture. Before any testing, our mentor gives one homework: "Pick a public programme, read its policy and scope, and tell me exactly what you are allowed to touch and what you are not." We use a public programme on HackerOne or Bugcrowd, for example GitHub's programme (hackerone.com/github) or any programme you like.

Goal of this lab

By the end you will have a one-page scope summary with:

In-scope assets (domains, apps, APIs) and out-of-scope assets.
Testing that is not allowed (for example denial of service, social engineering, spam).
Safe-harbour wording, reporting rules, disclosure rules and reward ranges.

What you need (all free)

A browser. A free HackerOne or Bugcrowd account is not needed for public pages.
A notes app or spreadsheet. About 30 minutes.

Safety and ethics

This lab is reading only. Do not scan, probe or test any asset, even an in-scope one, as part of this lab. Real testing needs a full understanding of the rules, the right account set-up and often a dedicated test account.

Steps

Open https://hackerone.com/directory/programs (or https://bugcrowd.com/engagements). Filter for programmes that offer bounties and are public. Pick one; GitHub is a good first choice.
Open the programme's Policy (or Program details) tab. Read the whole page once without taking notes.
Create your summary with these headings: Programme, Date read, In scope, Out of scope, Not allowed, Safe harbour, How to report, Disclosure, Rewards.
Open the Scope section (HackerOne shows a table of assets).

What you should see: a list of assets with types (Domain, Wildcard like *.example.com, iOS/Android app, API, Source code) and columns such as Eligible for bounty and Max severity.
Copy every in-scope asset into your summary, with its type and whether it is eligible for a bounty.
Copy every out-of-scope asset. Note tricky cases: a wildcard can include many subdomains, but some subdomains are often listed separately as out of scope (for example third-party hosted help centres).
Find the "not allowed" or "out-of-scope vulnerabilities" list and copy it. Typical items: denial of service and load testing, social engineering of staff, physical attacks, spam, automated scanning that floods the site, accessing other users' data beyond the minimum to prove an issue.
Find the safe harbour statement and write one sentence in your own words about what it protects and the condition (usually: you follow the policy in good faith).
Note the reporting rules (where, what to include, test accounts to use) and the disclosure rules (whether you may publish, and when).

What you should see: a clear rule such as "do not disclose without permission" or a disclosure timeline. Breaking it can cost you the reward and your account.
Answer three self-test questions in your notes: (a) Is a subdomain that is not listed in scope allowed? (b) Can you run a high-speed scanner? (c) If you find another user's personal data, what do you do?

Check your answer

(a) No. If it is not clearly in scope, treat it as out of scope (or ask the programme first). (b) Usually no, or only within stated rate limits; most programmes ban traffic that affects availability. (c) Stop immediately, do not download or keep more than the minimum needed to prove the issue, report it right away and delete any copies, following the programme's data-handling rules.

Ravindra Bagale's Tip

Save a PDF or screenshot of the policy page with the date you read it. Policies change, and you should always be able to show which rules you followed. Also: many companies, including many in India, have a "responsible disclosure" page without rewards. The same rules apply. Scope vachla, mag suruvat!

Common mistakes

Mistake	What happens	Fix
Reading only the bounty table	You miss the "not allowed" rules	Read the whole policy
Assuming every subdomain is in scope	You test something you are not allowed to	Only what is listed; ask if unsure
Ignoring "use your own test accounts"	You touch real users' data	Create and use only your own accounts
Publishing a finding on social media	Lost reward, ban, possible legal trouble	Follow the disclosure rules
Not saving the policy version	You cannot prove what rules applied	Save a dated PDF/screenshot

Self-check checklist

I picked a public programme and read the full policy.
My summary lists in-scope and out-of-scope assets with types.
I copied the "not allowed" tests.
I wrote safe harbour, reporting and disclosure rules in my own words.
I answered the three self-test questions.

0 of 5 done

Try-at-home challenge

Find one Indian company's "responsible disclosure" or "security" page (search for "responsible disclosure" plus the company name, then open the result on the company's own domain). How is it different from a HackerOne programme?

Check your answer

Typical differences: the scope may be broader or vaguer, there may be no monetary rewards (sometimes a hall of fame or swag instead), reports go to an email address like security@company rather than a platform, and safe-harbour wording may be shorter or missing. When rules are unclear, ask the company in writing before testing anything.

Samjla ka? In bug bounty the rules come first: read, summarise, then decide. Aata pudhe jaauya: Chapter 36 sets up monitoring for your own lab.