I started bug bounty in 2019, but in many ways, I didn’t fully jump in until mid-2023. I began hacking exclusively on Tesla’s program and had some good success. My first report was a hardware vulnerability in their infotainment system. Over time, I expanded into both hardware and web vulnerabilities, eventually working my way into the top 10 all-time on their program - where I still stand today.
That said, my participation was sporadic. I’d lock in for a month and find something cool, followed by stretches of inactivity. Tesla is an incredibly hardened company with a fantastic internal security team. Easy wins are rare. But in hindsight, starting there taught me a ton about discipline, rigor, and going deep. I believe sticking with a single, tough program early on, and hacking for fun rather than primarily for profit or bounties, made me a stronger hacker.
However, bug bounty really took off for me after submitting my first report on HackerOne. It wasn’t about the platform so much as the mental shift - realizing I could find success across multiple programs and even platforms. Once I broke that mental barrier, the whole game changed.
The First H1 Report
My first HackerOne report was completely accidental - but ended up being critical severity. I had TruffleHog’s Chrome extension installed while browsing a web application, and it popped a warning: a Stripe secret key had just loaded into my browser.
It turned out this app was unintentionally exposing a live, production Stripe secret key - something that could have allowed unauthorized access to financial infrastructure. I quickly validated that it wasn’t a test key and reported it.
That moment made everything click for me. Not just the adrenaline of finding a critical, but the realization that you can uncover impactful issues even outside the typical web proxy tool flow. Sometimes just using the product, observing the client-side behavior, or watching network traffic in dev tools is enough.
That single report gave me the confidence to treat other programs as viable targets - not just Tesla.
Which led me down a path of many more reports on HackerOne. I also continued to hack on Tesla and Bugcrowd, especially during some iOS research that I’ll link to later.
But I’m choosing to deep dive into HackerOne in particular as this is the first platform I’ve surpassed 100 reports on, and I think that makes for interesting data.
By the Numbers: Stats From the First 100
What did 100 reports equate to in platform stats?
As far as report status:
- 72 Accepted (Triaged + Resolved)
- 1 Pending Program Review
- 10 Duplicate
- 15 Informative
- 2 Self Close (requested invites to program, via emails connected to H1, which inadvertently created reports)
Overall:
- 82% valid (accepted + duplicate)
- 15% info
- 2% self close
Valid vs Info over time:
What about severity?
And lastly, bug class:
I am much more of a server-side hacker. I mostly focus on auth, access control, and business logic. I rarely look for XSS, and only have one report of such on H1. There was a season where I tried to shift into client-side because it seemed to be what was popular. But with more time, I’ve come to really like my current focus. I’ve had a fairly low rate of duplicates. And a good rate of high and critical findings. Which I attribute both in part to the bug classes that I primarily look for.
The biggest lesson from this data: every report, regardless of outcome, can teach you more than you expect - not just about hacking, but about reporting clearly, choosing targets wisely, and developing an intuition for what is a lead and what is a dead end.
Evolution of Technique and Tooling
Like most web hackers, I started with Burp Suite. Early on, I invested in a Pro license using some of my bounty earnings. The pro version is a fantastic tool - but at the time, it wasn’t the right fit for my skill level. I found myself running scans, chasing noise, and relying too heavily on the automated side of things. That led to a lot of dead ends.
Eventually, I got that urge to “use all the features” out of my system. I shifted toward more manual, targeted testing, all the more once I began to use Caido.
Switching to Caido was a major turning point. The clean UI helped me focus on what mattered. At first, as a newer tool, it didn’t have many plugins - and weirdly, that was an advantage. It forced me to understand every request and every response manually.
The fact that I can host Caido on a VPS and access it from anywhere - even my iPhone - made it perfect for my lifestyle. I could jump into a session, do some quick recon, or poke at a new endpoint from wherever I was.
I still keep Burp around for some advanced edge cases, but Caido is now my primary proxy tool.
That said, this is just my personal workflow and what I’ve come to like. Both tools are great.
Mistakes Made (and How I’d Avoid Them Now)
Around Q4 of 2023, I hit a wall. I was submitting more reports, but getting more informatives. The success rate dropped.
Looking back, I realized I had shifted toward reporting too quickly. I was testing new programs and submitting issues without fully evaluating their context or value. I was chasing volume over quality. Really, I wanted the thrill of finding something, so anytime I had a glimmer of hope, I’d latch on, perhaps too much, and end up submitting things that were a bit of a stretch in realistic security impact.
What I learned: it’s important to ask yourself “If I were the security engineer reading this, would I care?” If the answer isn’t a clear yes, keep digging. You’ll often find a better bug downstream anyway. But you really need to reflect on that. When we want something it is often hard to be impartial. So especially early on, it can be easy to oversell yourself on a bug or report.
I also got better at understanding how programs triage. Just because something is technically broken doesn’t mean it’s exploitable or risky in a way the program values.
And finally - I now spend more time polishing each report, which unironically led to faster triage and better outcomes. PoC videos with narration have become a frequent report addition for me.
Favorite Finds
My most interesting finding was likely with the research into iOS URL Schemes and OAuth flows This was also my first time collaborating. Julien (MrTuxRacer) was great to work with!
Another standout was a private report that I unfortunately can’t disclose due to program restrictions. But I can say it involved a bank, and I discovered an unauthorized money transfer vulnerability. In other words: literally hacking a bank. The bug allowed funds to be moved from any account without authorization, which was as serious as it sounds. Finding something like that was both wild and deeply satisfying. It reminded me that even mature companies can have critical flaws hiding just beneath the surface.
Community and Learning
I like to learn by doing. A ton of growth has come from simply reading docs and RFCs as I encounter something new in my testing. I’m not personally a fan of hacking labs or lessons. But that’s my learning style, and not a condemnation on those things or anyone who does benefit from them.
One of the biggest accelerators for me has been the Critical Thinking podcast and Discord community.
Certainly the hosts, originally Justin and Joel, and now Joseph, played a big role. But the community as a whole made a huge difference. Just hearing from successful hackers and full-time bug bounty hunters gave me a mindset shift: that this was actually possible. That it wasn’t just luck or noise, but something you could do with focus and effort.
Before that, I had been kind of stuck in a negative environment where most of my bug bounty information came from the r/bugbounty subreddit. Unfortunately, that subreddit, especially years back, has had a pretty negative tone. There’s a strong mindset there that bug bounty is a waste of time, that platforms take advantage of hackers, and that it’s impossible to have consistent or long-term success. I think this is shifting somewhat, but for much of my time starting out this was the case.
And sure, there is some unpredictability in this space, but I’ve found that with consistency and real effort, success is absolutely achievable. The podcast and the community gave me a kind of plausibility structure, a mental model, where I could genuinely see myself being successful. And once I had that, I started consistently investing time. And it paid off.
Advice for New Hackers
This space is quite conducive to imposter syndrome. So what should you do?
First: If you already have a technical background, don’t wait until you feel ready. Open up dev tools. Proxy some traffic. Read API docs. Try to make things break. You’ll absolutely waste time - and that’s okay. That time isn’t wasted. It’s how you learn.
Second: Be consistent. The hackers you admire are probably talented, sure. And probably knowledgeable. But odds are they are also very consistent. Keep showing up. Learn from every report - even the ones marked informative. Over time, your instincts sharpen. You stop fixating on whether something technically qualifies as a bug, and instead start asking the more important question: “Could this actually be exploited, and what would the real-world impact be?”
And finally, write clean, respectful reports. You’re not just proving that something’s broken - you’re building trust with the program.
What’s Next
I’m excited to participate remotely in my first Live Hacking Event (LHE).
Outside of that, I’m continuing to experiment with building simple plugins and tooling to aid my manual hacking - especially around Caido. I want to find ways to make hacking even more efficient.
Closing Thought
You won’t get better by chasing bounties, you’ll get better by chasing understanding. Focus on learning, stay consistent, and the rest will come.
Here’s to the next 100!