I Spent 3 Months on Bug Bounty — Here's What I Actually Earned and Learned
I Spent 3 Months on Bug Bounty — Here's What I Actually Earned and Learned
Every bug bounty success story you'll find online has the same structure: person starts bug bounty, finds critical vulnerability, earns thousands of dollars, quits their job. These stories are real — but they represent roughly the top 1% of participants. Nobody writes about the first three months.
I'm going to write about my first three months. Not because it's a success story — the earnings are modest and I'll give you the exact numbers — but because an honest account of what early bug bounty hunting actually looks like is more useful to most people than another interview with a full-time researcher earning $300,000 a year.
I started bug bounty hunting while studying cybersecurity through PortSwigger Web Security Academy and TryHackMe. My first program submission was three months ago. Here is everything — the findings, the rejections, the earnings, the learning curve, and what I would do differently.
- My actual numbers — earnings, hours, findings, rejections
- Month 1: Learning by failing
- Month 2: First real findings
- Month 3: Getting systematic
- What the guides don't tell you
- The real value of bug bounty beyond earnings
- How to start — what I'd do differently from day one
The Actual Numbers — Everything Transparent
Read those numbers before continuing. ₹12,400 over 180 hours is approximately ₹69 per hour. That is below minimum wage in most Indian states. If you are approaching bug bounty as a short-term income strategy, these numbers should be a clear signal: don't.
If you are approaching bug bounty as a skill development activity with the possibility of earning something while learning, the picture looks different. I will explain what those 6 valid findings and 180 hours actually taught me — and why I am continuing despite the numbers.
Month 1 — Learning By Failing
Month 1 — Everything I Got Wrong
0 valid findings · 8 reports · 6 duplicatesI started with false confidence. I had completed about 60% of PortSwigger's Apprentice labs, I understood the theory of XSS and SQL injection, and I had been doing TryHackMe for two months. I felt ready.
I was not ready. The gap between lab environments and real applications is large and non-obvious until you experience it. Here is what I got wrong in month one:
- I went straight for the most popular programmes. HackerOne's biggest programmes — major tech companies — have been tested by thousands of experienced researchers. Any low-hanging fruit was found years ago. Beginners should target programmes with less competition. I didn't know this and spent weeks testing programmes where my best findings were already known.
- I didn't read scope documentation carefully enough. Three of my eight reports were out of scope — testing on domains or functionality explicitly excluded from the programme. Reading scope documentation carefully is not optional; an out-of-scope submission is instantly dismissed regardless of the severity of what you found.
- My reports were low quality. My first accepted finding was rejected not because the vulnerability was invalid, but because my report didn't adequately explain the impact. Bug bounty triage is done by humans who are reading many reports — a clearly written, well-formatted report with a proof of concept and clear impact description matters. I was submitting findings without thinking about how to communicate them.
- I was testing too broadly. I would pick a programme and try to scan the entire attack surface looking for anything. Experienced researchers focus: pick a programme, understand its application deeply, choose specific areas where your skills are strongest, and test those areas thoroughly rather than skimming the surface of everything.
Month 1 earnings: ₹0. Valid findings: 0. Valuable? Yes — I understood what I didn't know.
Month 2 — First Real Findings
Month 2 — First Valid Reports
3 valid findings · 8 reports · ₹7,800 earnedMonth two was different because I changed my approach based on what failed in month one. Three specific changes:
- Switched to programmes with "Easy" ratings and fewer participants. HackerOne and Bugcrowd both surface programme difficulty signals. I looked for newer programmes in sectors I understood well (SaaS products, e-commerce) with relatively few resolved reports — indicating less competition, more remaining surface.
- Completed PortSwigger Practitioner labs before each testing session. Before spending time on a programme, I would complete the Practitioner-level lab for the vulnerability type I was going to test. This kept my skills sharper and more precise than relying on theory alone.
- Read 50+ public bug bounty disclosure reports. HackerOne's hacktivity feed shows disclosed reports from past submissions. Reading how experienced researchers found vulnerabilities, wrote reports, and communicated impact is more educational than any guide. I spent significant time in month 2 reading rather than hunting.
Finding 1: An IDOR (Insecure Direct Object Reference) vulnerability in an e-commerce platform's order management system. By modifying a numeric order ID parameter, I could view other users' order details including email addresses and delivery addresses. Accepted as Medium severity. Bounty: ₹5,200.
Finding 2: Reflected XSS in a search parameter of a SaaS dashboard application. Low severity because it required user interaction and the application had a relatively low-sensitivity context. Hall of Fame recognition, no monetary bounty.
Finding 3: Misconfigured HTTP security headers on a target's primary domain — missing security headers that enabled clickjacking potential. Informational severity, Hall of Fame mention, no monetary bounty. This is a common beginner finding — useful for a portfolio entry but not financially significant.
Month 2 earnings: ₹5,200 (plus 2 Hall of Fame entries). The IDOR finding was the entire monetary total.
Month 3 — Getting Systematic
Month 3 — Process Over Luck
3 valid findings · 7 reports · ₹7,200 earnedBy month 3, I had a methodology rather than ad-hoc testing. My process for each programme:
- Read the entire programme policy and scope document. Not skimming — reading it like a test. Note every excluded domain, every noted-as-won't-fix issue, every programme-specific expectation.
- Passive reconnaissance before touching anything. Subdomain enumeration (free tools: subfinder, amass), technology stack identification, exposed endpoints, JavaScript file analysis. Understanding the attack surface before testing it.
- Focus on authentication and authorisation logic. IDOR vulnerabilities and broken access control are consistently the most findable class of issues in real applications for someone at my skill level. SQL injection and XSS are the classic beginner targets but are heavily tested. Authorisation logic bugs are more application-specific and harder to auto-scan for, which means competition is lower.
- Write the report before the session ends. My report quality improved significantly when I documented findings immediately rather than reconstructing them later.
Month 3's significant finding was a Business Logic vulnerability in a booking application — I could modify the price parameter in an API request when creating a booking, resulting in bookings being created at arbitrary prices (including ₹0). The application validated the price was a valid number, but didn't re-validate it against the server-side price for the service. This earned a Medium bounty of ₹4,800.
I also had a second IDOR finding (similar to month 2's finding, different programme) for ₹2,400 and one Hall of Fame mention for a subdomain takeover — an expired subdomain that could be re-registered — which the programme didn't monetarily reward but acknowledged.
Month 3 earnings: ₹7,200. Slowly improving, but not linear — the business logic finding required significant time to identify and document.
What the Guides Don't Tell You
Honest Things Nobody Warned Me About
Duplicates are demoralising. Finding a valid vulnerability and having it marked as a duplicate — meaning someone already reported it before you — is the most common beginner experience. 11 of my 23 reports were duplicates. Some of those were genuinely good findings I had worked hard to discover and document. The correct response is to treat duplicates as confirmation that you found something real, log what you learned, and move to the next programme. It's easier to say this than feel it when it happens.
Response times vary enormously. Some programmes triage within hours. Others took 6-8 weeks to respond to my submissions. Waiting for responses while not knowing whether a finding is valid, duplicate, or out of scope is mentally difficult. Start multiple programmes simultaneously so you always have active work regardless of any single programme's response time.
The "easy" programmes are still hard. Easy ratings are relative to the average HackerOne participant — who is often significantly more experienced than a beginner. Easy programmes have less competition from elite researchers, not from beginners. Expect the first several submissions to find nothing monetisable regardless of how much you've studied.
Tax implications exist. Bug bounty income in India is taxable income. Once earnings become meaningful, you need to declare them. Track all payments received. This is not complicated but it is something guides consistently don't mention.
The Real Value Beyond Earnings
Here is what three months of bug bounty hunting actually taught me that TryHackMe and PortSwigger didn't, despite being excellent platforms:
- How to read and understand real application behaviour. Lab environments are designed to have vulnerabilities. Real applications are designed to work correctly and occasionally have vulnerabilities. Learning to distinguish normal application behaviour from suspicious behaviour requires exposure to real applications — which bug bounty provides and labs fundamentally cannot replicate.
- Report writing as a skill. Communicating a technical vulnerability clearly — with reproduction steps, impact analysis, and a proof of concept — is a genuine professional skill. My first few reports were poor. My later ones were significantly better. This skill is directly applicable to professional penetration testing report writing.
- Patience and systematic methodology. Bug bounty hunting is slow. The best researchers succeed through exhaustive, methodical coverage of an application's attack surface rather than clever intuition. Building this habit of systematic testing is more valuable than any individual finding.
- A public, verifiable portfolio. My HackerOne profile shows valid findings, Hall of Fame mentions, and a growing signal reputation. This is verifiable proof to a future employer that I can identify real vulnerabilities in real applications — which no certificate alone provides.
What I'd Do Differently From Day One
- Complete PortSwigger's full Apprentice curriculum before the first submission. I started too early. Each PortSwigger lab builds a mental model for finding that vulnerability class in real applications. Rushing past this phase costs time in the long run.
- Read 100 disclosed HackerOne reports before the first submission. Pattern recognition from existing reports is more valuable than technique knowledge in isolation.
- Start with programmes under 500 resolved reports. Less competition, more surface still available for a beginner to find something.
- Focus on authorisation logic from the start. IDOR and broken access control vulnerabilities are the most findable category at the beginner level. SQL injection and XSS are comprehensively tested by automated tools and experienced researchers. Manual authorisation testing is where individual researchers still find consistent results.
- Document everything in a personal tracker. Every programme tested, every finding, every rejection and why. Pattern recognition across rejections reveals gaps in testing methodology faster than any guide will tell you.
- Set a time budget, not an earnings target. Earnings in the first months are unpredictable and often zero. A time budget — "I will do 1 hour of active testing per day and 30 minutes of reading disclosures" — is achievable and generates consistent learning regardless of financial results.
Should You Start Bug Bounty?
Yes — with the right expectations. Bug bounty is not a reliable income source for beginners. It is the most effective way to develop practical web application security skills on real targets, in a legal and ethical context, with the possibility of earning something along the way. The portfolio value alone — verifiable, public evidence that you have found real vulnerabilities in real applications — is worth the investment of time.
Three months in, I earn less per hour from bug bounty than I would from a part-time job. I have learned more about web application security than I would have from a year of additional coursework. The ₹12,400 earned has covered my internet bill and some books. The skill development has been worth far more than that in terms of my career trajectory.
If you are a student in India looking to build a cybersecurity career: the combination of PortSwigger Web Security Academy (free, excellent) plus consistent bug bounty participation is the most effective path to job-ready skills that I have found. Not the fastest financially. The most effective in terms of actual skills and verifiable evidence of those skills.
Comments
Post a Comment