Bug bounty for beginners: a realistic roadmap

Bug bounty programs pay independent researchers for finding and responsibly reporting security flaws. It is a real way to build skills and sometimes income, but most beginners earn little at first, and many wait weeks or months for a first valid report. Plan for learning, not for quick money.

Step 1: learn how the web works (2 to 4 weeks)

• HTTP: requests, responses, methods, status codes, headers, cookies, sessions.
• HTML, JavaScript and how browsers run them.
• How a web app talks to a database (a little SQL).
• Basics of authentication, authorization and APIs (REST, JSON).
• Use browser developer tools until they feel natural.

Step 2: learn the common bug classes

Study the OWASP Top 10 and understand each class, how it happens and how it is fixed: injection, XSS, CSRF, access control (IDOR), security misconfiguration, SSRF, authentication flaws. Reading how a bug is fixed teaches you how to spot it. Our Web Security series covers many of them.

Step 3: practise legally on labs

Never test real sites without permission. Practise on:

• Deliberately vulnerable apps you run locally (OWASP Juice Shop, DVWA, WebGoat).
• Free labs such as PortSwigger Web Security Academy.
• Capture the Flag (CTF) events.

Learn a proxy tool such as Burp Suite Community, which lets you see and edit requests.

Step 4: choose programs and read the rules

Only test targets that invite you, and only what is in scope. Start with programs that are beginner friendly: clear scope, active triage and fair rules. Read the policy fully: allowed methods, forbidden actions (no denial of service, no accessing other users' data, no social engineering), and the safe harbor statement.

Step 5: build a repeatable method

Keep notes. For each target: map the features, list the inputs, test one class at a time and record what you tried. Quality beats quantity: one well-understood area is better than skimming a hundred.

Step 6: report well

A clear report with steps to reproduce, impact and a suggested fix is accepted faster. (See our guide to writing a report.)

Expect

• Duplicates and "informative" or "not applicable" closures are normal. Do not take them personally.
• Competition is high on popular programs. Look for less crowded programs and deeper logic issues (business logic, authorization) rather than only simple scanner-type bugs.
• Patience: consistent weekly practice matters more than long, rare sessions.

Rules to live by

• Stay in scope. Never access, change or delete data that is not yours.
• Use test accounts you create.
• Stop and report as soon as you prove the issue. Do not go deeper to "see how bad it is".
• Keep findings private until the program allows disclosure.

Takeaway: learn the web and the common bug classes, practise in labs, test only in-scope programs, and write clear reports. Treat the first months as training.

---

Bug Bounty series, Part 1 (getting started): 1 of 4.