It started with curiosity, confusion, and a lot of failure.

I didn't have a strong security background. I wasn't "gifted," special, or naturally talented. I didn't have mentors guiding me step by step.

This article is about why I started, what went wrong, what finally worked, and what beginners can realistically learn from my journey.

Why I Started Bug Bounty

It all started in 2020, during the COVID-19 lockdown.

I was in my second year of college, stuck at home with a lot of free time. Like many others, I was searching online for ways to earn money, and that's when I discovered bug bounty.

Bug bounty felt open and fair. If you could find real security issues, you could get rewarded.

At the time, I believed hard work would quickly turn into results.

That assumption was wrong.

But the reason I started was still valid — and it's what kept me going even when progress was slow.

What I Did at the Beginning

In the beginning, I focused mostly on learning.

I started with an ethical hacking course on Udemy, along with TryHackMe and the PortSwigger Web Security Academy. I spent a lot of time watching YouTube videos, reading blogs, and following experienced hunters on Twitter.

I tried to understand different vulnerabilities and tools. With confidence, I submitted reports believing they were valid.

Most of them weren't.

Still, all that learning helped me beyond bug bounty. Since I'm a computer science student, this knowledge directly helped me during my semester exams. I was able to apply what I learned, pass my exams, and gain confidence.

Looking back, it's something I truly appreciate — because it indirectly improved other areas of my life as well.

My Struggle and Failures

This phase was the hardest.

• Reports got rejected
• Many were marked as "informative"
• Some turned out to be duplicates

Seeing others post their wins online made it even harder.

Self-doubt slowly started creeping in. At times, I genuinely felt like I wasn't good enough. I seriously questioned whether I should continue or walk away.

But looking back, this phase shaped me more than any success ever did.

My First Win

My first valid bug didn't come quickly.

After two years, on May 6, 2022, I received my first bounty — $500 from Facebook.

But when it finally happened, everything changed.

It wasn't about the payout. It was about validation.

For the first time, I knew this wasn't luck. It was skill, learning, and hard work paying off.

I was extremely happy at that moment. When converted to INR, it was around ₹40,000, which felt huge at the time. Even my parents couldn't believe it was real money.

That single report changed how I saw bug bounty — and how seriously I believed in myself.

Things I Learned Along the Way

Bug bounty taught me some important lessons:

• Bug bounty has both ups and downs
• It's a marathon, not a race
• Rejections are a normal part of the process
• Consistency beats motivation
• Manual hunting is often better than heavy recon
• Deeply explore every feature of the web application
• Never give up, even when progress feels invisible
• Focus on a single program with many features
• I mainly focus on access control issues, such as:
• Privilege escalation
• Permission bypass
• Business logic vulnerabilities

Progress was slow — but it was real.

My Bug Bounty Timeline

To set realistic expectations, here's how my journey actually looked:

• 2020 — Discovered bug bounty, lots of confusion, zero valid bugs
• 2021 — Hands-on practice, many failures, constant self-doubt
• 2022 — Found my first valid bug and earned $500
• 2023 — Focused on a single private program; earned around $18,000
• 2024 — Combined public and private programs; earned around $23,000
• 2025 — Focused hunting, still learning; crossed $32,000+, reaching around $42,000

There was no overnight success — only steady progress.

Throughout this timeline, I faced many ups and downs, setbacks, and moments of doubt. But consistency made the difference.

Tips for Beginners

If you're just starting out, this is what I'd suggest:

• Focus on one area instead of trying to learn everything at once
• Practice more, study more
• Expect rejections — they're completely normal
• Don't chase money early
• Stay consistent for months, not days

Bug bounty is a long journey. It requires consistent learning over months, and yes — luck also plays a role. Some days you'll hunt for hours and find nothing, and that's completely normal.

Follow This Path

1. Start with the Basics

• TryHackMe: Intro to Cyber Security, Pre-Security, Web Fundamentals
• Learn HTTP, DNS, cookies, sessions (YouTube is enough)

2. Learn Web Security

• TryHackMe: Web Application Security, Jr Penetration Tester
• PortSwigger Academy: Complete labs (Authentication & authorization issues, Business logic issues, IDOR, etc.)

3. Begin Real Bug Hunting

• Join HackerOne, Bugcrowd, or Intigriti

4. Tools to Learn

• Burp Suite

Stay consistent, and let skill + luck do the rest.

Bug Bounty Is a Long-Term Game

• Hunt on programs with different roles (admin, user, etc.)
• Read documentation carefully and look for "no" statements (e.g., "this role can't see this" or "can't perform this action") → then try to bypass those restrictions
• Pick a large program with multiple roles and permissions and hunt there for 2–3 months (e.g., Zoho, fresh works, Slack)
• Use Google dorks to find bug bounty programs that involve roles and permissions
• Read more write-ups and observe:
• Which programs other hunters focus on
• What bug types they report

Learn From Others (Loop Learning)

To gain more insights, learn from other hunters:

• For example, check my Twitter/X profile: https://x.com/iamgk808
• Read through all the posts to understand tips, tricks, and mindset
• Open my Following list and explore those profiles
• From those profiles, check their following lists
• Repeat this process — it becomes a loop of continuous learning

A Real PoC: GitLab Case Study ($32,000 bug)

To make this article practical, I'm sharing a real example.

In this section, I'll briefly explain:

Bug Name

IDOR able to add any project runner to the attacker project and manage the runner via POST /api/v4/projects/{projectId}/runners

Setup and Prerequisites

To reproduce this, you need two users on a GitLab Enterprise Edition (EE) instance:

1. Victim: A user with a private project and an active project runner.
2. Attacker: A user with a group where they can assign custom roles.

Step 1: Victim Environment Setup

1. Log in as the Victim.
2. Create a new private project (e.g., victim-private-repo).
3. Navigate to Settings > CI/CD > Runners.
4. Create a new Project Runner and register it to the project.
5. Note the Runner ID (visible in the URL or the runner list).

Step 2: Attacker Preparation

1. Log in as the Attacker.
2. Create a new group (e.g., attacker-group).
3. Go to Settings > Roles and Permissions and create a Custom Role based on the Guest role, but enable the Manage runners permission.
4. Invite a secondary attacker account (or yourself) to a project within this group (attacker-project) using this new custom role.

Step 3: The Exploitation (IDOR)

The vulnerability lies in the API endpoint used to associate runners with projects. The attacker can "claim" the victim's runner by referencing its ID.

1. Identify the project_id of the Attacker's project.
2. Use a tool like curl or Postman to send a POST request to the GitLab API:

curl --request POST "https://gitlab.example.com/api/v4/projects/<ATTACKER_PROJECT_ID>/runners" \      --header "PRIVATE-TOKEN: <ATTACKER_TOKEN>" \      --form "runner_id=<VICTIM_RUNNER_ID>"

1. Observation: Despite the runner belonging to a private project the attacker has no access to, the API accepts the request.

Step 4: Verification of Impact

1. Navigate to the Attacker's project settings: Settings > CI/CD > Runners.
2. The Victim's runner will now appear in the attacker's project.
3. The attacker can now edit, pause, or delete the victim's runner, effectively hijacking the CI/CD resources of the victim.

Impact and Remediation

This IDOR allows attackers to pivot into other projects' CI/CD pipelines, potentially leading to unauthorized code execution if they can trigger builds on the hijacked runner or disrupt development workflows by disabling runners instance-wide.

Final Thoughts

Bug bounty didn't change my life overnight.

But it taught me patience, problem-solving, and discipline.

If you're failing right now, that's normal. Failure isn't the end here — it's part of the process.

Keep learning. Keep testing. And don't quit too early.

Let's Connect

If you found this journey helpful and want to learn more about bug bounty, mindset, and real-world hunting experiences, feel free to connect with me:

• Twitter / X: https://x.com/iamgk808
• LinkedIn: https://www.linkedin.com/in/iamgk808