How Bug Bounty Platforms Work

What if companies openly invited people to look for weaknesses in their systems, and thanked them, sometimes with a reward? That is the idea behind bug bounty programs. They have opened a legal path for self-taught testers to practice on real systems. But the path has strict rules, and ignoring them turns a hobby into a legal problem. This lesson explains how the model works, what you can and cannot do, and how to prepare.

The basic idea

A bug bounty is an agreement: an organization publishes rules saying "you may test these systems, in these ways, and report problems to us like this". In return, security researchers who follow the rules and report valid vulnerabilities are acknowledged and, in many cases, rewarded. The organization gains the eyes of many testers; the testers gain legal clarity, experience and recognition.

Think of it like a "report potholes" service run by a city. The city invites residents to report road problems, tells them where and how, and thanks them. It does not invite residents to dig up the road to look for pipes.

The actors

• The organization (sometimes called the program owner) that owns the systems and decides the rules.
• The researchers, also called hunters or testers, who look for vulnerabilities.
• The platform (in many programs), an intermediary that hosts the program, collects reports, helps with triage and handles payments and legal terms. Some organizations run their program directly on their own site.
• The triage team, who read reports, reproduce the problem and decide on validity and severity.

Platforms differ in their features and fees, and the market evolves. Rather than recommending a particular one, learn the common principles so that you can read any program with confidence.

Types of programs

• Vulnerability disclosure programs (VDP): an organization says "we welcome reports and will not take legal action against good-faith researchers who follow our policy", but offers no payment. These are great starting points for beginners.
• Public bug bounty programs: open to anyone, with rewards for valid reports. They are popular, so competition is intense and many easy findings are already reported.
• Private programs: open by invitation, often after building a reputation. Fewer testers means a better chance of valid findings.
• Time-limited challenges and live events, sometimes with a defined test environment.

Reading a program policy

The policy is the only thing that matters. Read the entire page, every time, as if it were a contract (it is). Key sections:

• In scope: the exact systems, domains, applications or versions you may test. Anything not listed is out of scope.
• Out of scope: assets and issue types excluded. Common exclusions include certain denial-of-service testing, social engineering of employees, physical attacks and third-party services.
• Allowed and forbidden methods: for example, no automated high-volume scanning, no access to other users' data beyond what is needed to prove the issue, no modification or deletion of data.
• Test accounts: whether you must create your own accounts and what data you may touch.
• Safe harbor statement: the organization's commitment not to pursue legal action against researchers who comply with the policy. Notice how it is worded, and its limits. It generally cannot protect you if you break the rules, nor can it cover systems owned by someone else.
• Reporting format and channel.
• Reward and recognition rules: how severity is rated, whether duplicates are paid, and whether you are acknowledged publicly.
• Disclosure policy: whether, when and how you may talk about the vulnerability publicly.

The life of a report

1. Submission: you send a clear report with steps to reproduce (lesson 6.2).
2. Triage: the team reproduces the problem, may ask questions and classifies it. Possible outcomes: valid, duplicate (someone reported it first), not applicable, informative (true but low impact) or out of scope.
3. Severity rating: often based on a standard scoring system such as CVSS, adjusted for the context of the organization.
4. Fix: the organization's developers correct the issue.
5. Verification and reward: you may be asked to confirm the fix. Rewards depend on the program's rules and on the severity, and vary enormously.
6. Disclosure: after the fix, and only according to the policy, details may be published.

Delays are common. Be patient and polite. Insisting aggressively is a sure way to harm your reputation.

Responsible, coordinated disclosure

Coordinated vulnerability disclosure means you report the problem privately to those who can fix it, give them reasonable time and agree on when to publish details, so that users are protected before attackers can take advantage. The opposite, publishing a vulnerability immediately without warning, may put users at risk and can have legal consequences. Equally, demanding payment under threat of publication is blackmail, not research.

When a vulnerability concerns an organization without any program, the cautious route is to avoid testing it at all. If you stumble on a problem by chance, in France you may report it to ANSSI, which maintains a channel for vulnerability reports (see cyber.gouv.fr for the current procedure). Do not dig further to "prove" the problem.

Ethics and professionalism

• Minimal impact. Prove the issue with the least intrusive action. Never access more data than necessary, never modify or delete, never disrupt service.
• Protect personal data. If you see real personal data, stop, do not copy it and describe it in your report without including it.
• Stay in scope. A great finding outside the scope still goes unrewarded and may be a violation.
• Respect confidentiality. Do not share details of private programs.
• Be honest. No inflated severity, no copy-paste of automated scanner output presented as research.
• Be courteous. Triage teams are people with many reports to read.

Realistic expectations

Many beginners imagine quick rewards. Reality is more modest:

• Most reports from beginners are duplicates or low severity, particularly in popular public programs.
• Income is irregular. Treat bug bounty as a learning path and a complement, not as a salary.
• The best predictors of success are patience, depth in a specific area, careful reading of the policy and good reports.
• Reputation builds slowly, through consistent quality.
• Avoid burnout: set time limits and take breaks.
• Taxes and legal status apply to rewards; in France, inform yourself about the correct declaration of income.

A beginner's roadmap

1. Finish the training platforms: labs on DVWA, Juice Shop, PortSwigger and TryHackMe.
2. Study the OWASP Top Ten and the API risks of chapter 5.
3. Read a handful of published, anonymized reports to learn what good ones look like.
4. Start with a VDP or a program with a wide scope and clear rules, and read the policy twice.
5. Choose a narrow focus, such as a single vulnerability class, and become good at it.
6. Write down what you learn in a private notebook, even when you find nothing.

Your turn: read a policy like a pro

Here is an extract of a fictional program policy. Answer the four questions below.

Program: LabShop security program
In scope:       shop.labshop.example (production web application)
                api.labshop.example (version 2 only)
Out of scope:   all other subdomains, employee phishing,
                denial-of-service testing, automated scanning above
                5 requests per second, third-party payment page
Rules:          use only accounts you created yourself
                do not access other users' data
                stop and report if you see personal data
Rewards:        paid for valid, in-scope, first reports
Safe harbor:    we will not pursue legal action for good-faith
                research within this policy

1. You find a possible weakness on old.labshop.example. May you test it?
2. You want to run a high-speed automated scanner on the shop. Is that allowed?
3. While testing your own account, you notice that you can view another customer's address. What do you do?
4. Does the safe harbor sentence protect you if you test the third-party payment page?

See a solution

1. No. Only the two listed assets are in scope. Testing the old subdomain is outside the permission. You may not test it; you could mention the observation only if the policy invites such reports, without further probing.
2. Not at high speed. Automated scanning above 5 requests per second is out of scope. Keep within the rate limit, or better, do manual, targeted tests.
3. Stop and report. You accessed data of another user, which is exactly the situation the rules describe. Do not look at more, do not save the data, describe the flaw and steps to reproduce using your own accounts as much as possible, and submit it.
4. No. The payment page is explicitly out of scope, and the safe harbor only covers research within the policy. It also belongs to a third party that has not given you permission.

Portfolio step

Create a folder 06-bug-bounty-community in your portfolio. Add reading-a-policy.md with your answers and a checklist you will use before testing any program: scope, exclusions, rate limits, test accounts, safe harbor, disclosure rules. This checklist shows maturity and respect for rules, a quality all employers look for.

The next lesson shows how to turn a finding into a report that gets taken seriously.