What is Cross-Site Scripting (XSS)? Real Bug Bounty Example Explained
madhukarreddyeng
3 min read
When I first started learning cyber security, Cross-Site Scripting (XSS) felt like just another theory topic.
But things changed when I actually found an XSS vulnerability during a bug bounty program — and got paid for it.
In this post, I’ll explain what XSS is, how it works, and share a simplified version of a real-world scenario.
What is Cross-Site Scripting (XSS)?
Cross-Site Scripting (XSS) is a vulnerability that allows an attacker to inject malicious scripts into a website.
When another user visits that page, the script runs in their browser.
This can lead to:
- Session hijacking
- Data theft
- Unauthorized actions
How XSS Works (Simple Explanation)
A website takes user input and displays it without proper validation.
Example:
If a comment box allows any input and directly displays it, an attacker can inject JavaScript.
Example Payload:
<script>alert(1)</script>If the website doesn’t filter this, the script executes in the browser.
Types of XSS
1. Stored XSS
Malicious script is saved in the database and shown to all users.
2. Reflected XSS
Script is reflected from the request (like URL parameters).
3. DOM-Based XSS
Happens on the client side via JavaScript manipulation.
Real Bug Bounty Experience (Simplified)
While testing a web application, I noticed an input field that accepted user data.
When I entered normal text, it displayed correctly.
So I tried something different.
Step 1: Test Input
I entered:
<script>alert(1)</script>Step 2: Observe Behaviour
Instead of blocking it, the application executed the script.
This confirmed a Reflected XSS vulnerability.
Step 3: Report
I documented:
- Affected endpoint
- Payload used
- Steps to reproduce
The report was accepted, and I received a reward.
How to Prevent XSS
If you’re building applications, here’s how to stay safe:
- Validate and sanitize user input
- Escape output properly
- Use Content Security Policy (CSP)
- Avoid directly rendering user input
What is Rate Limiting Vulnerability?
Another issue I found was related to rate limiting.
The application allowed unlimited requests to a sensitive endpoint.
Why this is dangerous:
An attacker can:
- Perform brute-force attacks
- Abuse APIs
- Cause server overload
Real Scenario (Simplified)
There was an API that handled login attempts.
Even after multiple failed attempts, it didn’t block or slow down requests.
This means:
- No request limit
- No IP blocking
- No delay mechanism
How to Fix Rate Limiting Issues
- Limit requests per IP
- Add delays after multiple attempts
- Use CAPTCHA
- Implement account lockouts
Why These Vulnerabilities Matter
These are not rare issues.
They are still found in:
- Startups
- Production applications
- Even large platforms
Understanding them gives you a strong edge in cyber security.
Is Bug Bounty Worth It?
From my experience, yes — but only if you:
- Focus on learning
- Practice consistently
- Understand real vulnerabilities
Even one valid finding can be rewarding.
Final Thoughts
Cyber security becomes much clearer when you see real-world issues instead of just theory.
Finding vulnerabilities like XSS or rate limiting is not just about tools — it’s about understanding how systems behave.
What You Should Do Next
Try this safely:
- Use test environments (like intentionally vulnerable apps)
- Practice XSS payloads
- Learn how applications handle input
⚠️ Important Note
Always test only on authorized platforms or bug bounty programs. Unauthorized testing is illegal.
👉 Bonus Tip
If you’re learning DevOps, combine it with security testing. This combination is highly valuable and in demand.