💡 Introduction
When I started learning bug bounty hunting, I never expected to actually find a real vulnerability. But one day, I found my first XSS (Cross-Site Scripting) bug — and that moment completely changed how I look at web security.
In this post, I’ll walk you through exactly how I found it, what I learned, and how you can do the same.
⚙️ Step 1 – Setting Up
Before testing, I made sure I was working in a legal environment — either a bug bounty program or my own test environment.
My setup was simple:
-
A browser with DevTools
-
Burp Suite for intercepting requests
-
A notepad for documenting every request and response
Always make sure you have permission before testing any website.
🔍 Step 2 – Finding Input Points
XSS lives where user input is reflected in a web page.
I started looking for:
-
Search boxes
-
Contact forms
-
Profile bio fields
-
Comment sections
-
URL parameters like
?q=test
When I found a form that showed my input back on the page, I knew it was worth testing.
🧪 Step 3 – Testing for Reflection
I submitted a harmless payload:
If the alert box appears, it means the input wasn’t properly sanitized — a potential Reflected XSS.
Sometimes it doesn’t show immediately. That’s when I check the page source or use Burp Repeater to analyze responses manually.
💾 Step 4 – Stored or DOM XSS?
After a few tests, I realized my payload didn’t disappear after refresh — it was saved in the database and shown to other users.
That meant it was a Stored XSS, which is more impactful because it affects anyone who visits that page.
🧠 Step 5 – Understanding the Impact
I thought:
“If this runs JavaScript in another user’s browser, what could I do?”
✅ Steal cookies (but never do this in real tests!)
✅ Modify the page content
✅ Redirect users to phishing pages
Even though I only used a simple alert, I knew the real risk was session hijacking or data theft.
🧾 Step 6 – Writing the Report
Here’s how I structured my first report:
Title: Stored XSS in Profile Bio Field
Summary: User input in the profile bio is not sanitized, allowing arbitrary JavaScript execution.
Steps to Reproduce:
-
Log in to your account
-
Go to profile settings
-
Add this payload in the bio field:
-
Save and visit another user’s profile page
Impact: Executing arbitrary JavaScript in other users’ browsers.
Recommendation: Escape user input before rendering, apply CSP.
🧩 Step 7 – Lessons Learned
-
Always use safe PoC payloads like
alert(1)— never exploit the system. -
Document everything: request, response, screenshot, timestamp.
-
Keep your explanation simple and professional — make it easy for the security team to understand.
-
Respect responsible disclosure — never share details before the fix.
🚀 Step 8 – After the Report
A few days later, the program team confirmed my finding and marked it as Valid XSS 🎉
That feeling was priceless — not just for the reward, but because I had proven to myself that I could really find vulnerabilities.
🔑 Key Takeaways
-
Start small — even a simple reflected XSS can teach you a lot.
-
Don’t chase the money first; focus on learning the process.
-
Always report responsibly and ethically.
-
Every bug, even a small one, is a step closer to mastering bug bounty hunting.
🏁 Conclusion
Finding my first XSS wasn’t luck — it was persistence.
I learned that curiosity, patience, and solid documentation are the real keys to success in bug bounty hunting.
If you’re still looking for your first bug, don’t give up.
Your “alert(1)” moment is coming soon. 💪