My Bug Bounty Methodology After 100 + Valid Submissions

Introduction

Rajankumarbarik

~6 min read · December 24, 2025 (Updated: December 24, 2025) · Free: No

Introduction

After submitting 100+ valid bugs and receiving messages from fellow beginners, I realized one important thing to share with you: the methodology that I have built so far.

In the next few minutes, I promise that if you stick till the end, you'll gain something valuable to add to your bug bounty cart.

Disclaimer ℹ️

If you came here to get or download some hidden secret tools and follow some commands to find bugs, then this blog is not for you. This blog is more about my own experience and my approach to targets — from selecting the right targets to finally getting rewarded.

Why Methodology Matters More Than Talent

In my opinion, this field is not just about luck or fancy payloads, but about following the right way to look for bugs. That's where methodology comes into play — it guides you on the correct path to follow.

How My Approach Evolved (Beginner → 100+ Valid Bugs)

For easier understanding, I divided my methodology into two parts.

But before moving to that part, let's first look at the very first step of any methodology.

Target Selection

Selecting the right target itself is very subjective, especially when you are hunting on a public platform where many programs exist with different bounty ranges, scopes, and engagement levels. As beginners, we often make a big mistake by going for high-bounty targets.

If you choose a big company like Tesla that pays almost a million-dollar bounty, you may not find good bugs because those targets are already heavily hunted. My approach while selecting a target is to look at the submission rate and the program scope.

The wider the scope, the higher the chances of finding unique bugs. So, try to choose wildcard targets with programs that have a lower submission rate

After target selection

After selecting a target, don't immediately start running tools and scanners, which is what most people do in bug bounty. Instead, I create a mind map to map the target's architecture and attack surface . You can use any mind-mapping software or application for this purpose.

For example, if my target has the scope *.example.com, I first collect all subdomains from every resource I have, such as Wayback, VirusTotal, Subfinder, Sublist3r, or any online tool(including active enumeration ). Then I combine all the results, remove duplicates, filter live hosts, and prepare a clean list of all target subdomains. After that, I spread them on my mind map to get a visual view of the wider attack surface.

Recon with a objective

Now here is another part where many beginners get confused. Even when I was starting out, I made this mistake, so I thought it was worth mentioning so you don't do the same.

During the reconnaissance phase, most people try to do everything at once — running Nmap scans, scanning JavaScript files, doing OSINT, and more. However, this is not an appropriate or strategic way of testing.

What I do instead is this: after identifying all live targets, my first goal is to check for WAFs or CDNs. Yes, this is the approach I follow. Think of WAFs as the first line of defense for any web application — they often block almost every malicious request you send, whether it's an XSS payload or an SQL injection payload, preventing it from reaching the backend server.

In such cases, I filter out the subdomains that have WAFs and keep them for later testing, such as attempting bypasses or finding the origin IP. The subdomains that do not have any kind of WAF are the ones I test first.

The objective here is simple: when there is no protection blocking you, you can test many things freely and efficiently, increasing your chances of finding impactful bugs instead of spending too much time trying to bypass protections on heavily secured targets.

Smart Use of Vulnerability Scanners

Now comes the most favorite part for beginner hunters, which is running vulnerability scanners 😄. I know most people use this as the sole part of bug hunting, but using scanners in a smart way is what matters most, instead of using them everywhere and just spreading noise and generating SIEM alerts without results.

After the initial recon and after figuring out the list of targets that are not behind any WAFs, those are the best places to run vulnerability scanners. The reason is simple: since there is no network-level protection, you can test more intrusively on multiple parts or aspects of the target while focusing on other targets manually in the background.

My agenda is simple: after filtering out non-WAF IPs, I use scanners on them, but in a limited or permitted amount of requests per second, as aggressive scanning can cause DOS-like scenarios.

So when you use scanners, keep in mind to use fewer threads and lower request rates.

Useful vulnerability scanners:

Burp Suite Professional Scanner
Acunetix Pro
Nuclei (Free)

As I mentioned earlier, I divided my methodology into two parts. What you have read above was the first part, which is mainly about surface-level bug discovery. Vulnerability scanners are useful, but they are less capable than a thoughtful hacker when it comes to finding logical bugs, which is why I divided my approach into two parts.

After running surface-level scans, if you find any low-hanging bugs such as reflected XSS, CSRF, or known CVEs, that's good — you can report them. However, to discover higher-impact bugs such as business logic issues, you need to follow my second approach, which is…

Looking For Impact

Now in this section, I will cover the core part of my methodology, which most beginners avoid spending time on.

Finding injection bugs such as XSS or SQLi can be done with vulnerability scanners, but what separates an elite hacker from a beginner is testing for business logic bugs.

In this section, I have categorized a few vulnerabilities that you can focus on while testing:

IDOR (Insecure Direct Object Reference)
BAC (Broken Access Control)
Business Logic Issues
AI Prompt Injection

These are security issues that cannot be tested effectively using vulnerability scanners, so I usually test them manually. From my experience with previous findings, I have discovered several high to critical severity issues that companies truly care about, and most of them came from the 4 categories mentioned above.

Showing Impact

Now this is another crucial aspect of bug bounty hunting, where you have to prove what you find. This is called the report writing phase, where you need to craft a clear, descriptive, and impactful report that gets straight to the point.

I know most people use AI tools for this job, and that's not a bad thing — you can do that. However, what I personally do is write two important sections of the report on my own: Steps to Reproduce and Proof of Concept (POC), because these are the most crucial parts of any bug bounty report that triagers look at closely.

Here is my preferred report format:

Description
Steps to Reproduce
Impact
Recommendation
Additional Details

One thing I always keep in mind while writing any bug bounty report is that the report should clearly demonstrate impact, be straight to the point, contain no unnecessary stories, and include clear reproduction steps.

By following the format mentioned above, you can easily grab the triager's attention.

Conclusion

So this was all about the methodology that I follow during my bug hunting process. I know it's not possible to mention everything in detail in a single blog — this was an overall, non-technical, surface-level overview of my methodology.

If you want more detailed guidance, you can follow my page, as I will publish deeper content in my future posts.

Thanks for reading.