Bug Hunting 101: How to Find XSS in Unusual Places 🕵️

---

Bug Hunting 101: How to Find XSS in Unusual Places 🕵️

👉 Free Link

Welcome, fellow hacker! 🚀 If you’ve ever chased bounties or simply explored the world of web security, you’ve likely crossed paths with Cross-Site Scripting (XSS). But what if I told you that most researchers miss the juiciest XSS bugs because they’re stuck looking in all the obvious places?

In this post, we’re going off the beaten path. Let’s explore unusual locations where XSS vulnerabilities hide — and learn the tools, techniques, and mindset needed to uncover them. 🧠

---

🎯 What is XSS, Really?

Before we dive deep, let’s quickly recap:

Cross-Site Scripting (XSS) is a vulnerability that allows an attacker to inject malicious JavaScript into a web application. When another user loads the affected page, the script executes in their browser.

Types:

• Stored XSS: Script is permanently stored on the server (e.g., in a database).

• Reflected XSS: Script is reflected off the server (e.g., in an error message or search result).

• DOM-based XSS: The script is injected into the page via client-side JavaScript.

But you knew that, right? 😉 Let’s level up.

---

🔍 Where Everyone Looks (And Why That’s Not Enough)

Most beginners scan these:

• Search bars

• Comment sections

• Contact forms

• URLs and query parameters

And while you should check these, you’re competing with thousands of other hunters. If the app is mature, these are already patched.

To find unusual XSS, we must dig deeper. Let’s go! 🧑‍💻

---

🧠 Mindset Shift: Think Like a Developer

To find hidden XSS bugs, you must:

• Think like a developer: What features need to reflect data?

• Check edge cases: Developers often test what works, not what breaks.

• Break expectations: Use payloads that exploit assumptions.

---

🚪 1. HTTP Headers — The Overlooked Entry

Most hunters forget that HTTP headers can be reflected in responses or used in DOM logic.

Examples:

• Referer

• X-Forwarded-For

• User-Agent

• Origin

Try this:

curl -H "User-Agent: <script>alert('XSS')</script>" https://target.com

💡 Tip: If you find a header being reflected, try common XSS payloads.

Tools:

Burp Suite: Burp Suite is one of the best tools for detecting and exploiting Cross-Site Scripting (XSS) vulnerabilities. Here’s a complete guide on how to use Burp Suite for XSS — both manual and automated approaches.

https://portswigger.net/burp

• httpx: The httpx tool is a fast and flexible HTTP toolkit written in Go, developed by ProjectDiscovery. It’s widely used in bug bounty, recon, and automation workflows.

https://github.com/projectdiscovery/httpx?tab=readme-ov-file

---

🗺️ 2. Non-HTML Contexts (JSON, SVG, XML, PDF)

XSS can occur outside HTML too. Examples:

• SVG injection (<svg onload=alert(1)>)

• PDF generation with unsanitized input

• JSONP endpoints

• XML data rendering on frontend

💥 Tip: Look for file exports that include your input.

Example payload for SVG:

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

---

🧾 3. PDF Exports and Report Pages

Many apps allow exporting data to PDF. If input gets embedded without sanitization, you can trigger JavaScript.

👉 Look for:

• Invoice generators

• Report tools

• Admin dashboards with PDF export

PDF.js used in the browser can execute embedded scripts. Dangerous combo! ⚠️

---

🧪 4. WebSocket and GraphQL Endpoints

Developers often forget to sanitize input in:

• WebSocket messages

• GraphQL queries/mutations

🚨 If this data is later rendered, boom — XSS.

mutation { addComment(text: "<script>alert(1)</script>") }

Tools:

• Altair GraphQL

• WSSi

---

🧳 5. File Upload Names & Metadata

Many apps let users upload files. The file name, title, or even metadata may be rendered later.

💡 Rename your file to:

"><script>alert(1)</script>.jpg

Try modifying EXIF metadata too:

• Use ExifTool

exiftool -Title="<script>alert(1)</script>" image.jpg

---

🔐 6. Login Pages & Error Messages

XSS in login? 😱 It happens.

Test fields like:

• Username

• Email

• 2FA input

• Error response messages

Some apps reflect failed logins or validation messages. Inject here.

---

🛠️ 7. Desktop & Electron Apps

Yes — even desktop apps using Electron or webview components are vulnerable to XSS.

If the app renders remote content or local HTML with user input, you can often trigger XSS.

Explore the app’s source if possible:

• Look for unsanitized innerHTML

• See what libraries are loaded

---

🧪 XSS Payloads for Unusual Contexts

Here are some useful payloads you can experiment with:

• SVG: <svg/onload=alert(1)>

• Image error: <img src=x onerror=alert(1)>

• Meta tag: <meta http-equiv="refresh" content="0;url=javascript:alert(1)">

• JavaScript URI: javascript:alert(1)

More payloads:

• PayloadsAllTheThings/XSS

• XSS Cheat Sheet

---

⚙️ Bonus Tools You Should Try

• XSStrike

• Dalfox

• KXSS

• XSS Hunter

• Burp Suite (of course!)

These tools help you automate and detect reflection points, unusual DOM patterns, and potential sinks.

---

💥 Real-World Examples

1. XSS in Error Message:
   A fintech app showed an error message with a user’s name, allowing <script> injection during login failure.

2. XSS via File Metadata:
   A medical app displayed uploaded patient images and titles directly — a script in the image title popped an alert on the admin dashboard.

3. XSS via GraphQL Mutation:
   A productivity app had XSS when you posted a comment via a GraphQL mutation. It showed in the team dashboard with no sanitization.

---

🧠 Final Tips to Stay Ahead

• Don’t stop at what’s visible — test every layer.

• Think beyond the UI — what else reflects input?

• Look where developers assume no one looks.

• Always use tools + manual validation.

👋 Stay Connected

If you enjoyed this guide and want more practical tutorials, recon checklists, and hacker strategies, stay in touch:

• 📬 FREE Newsletter: thehackerslog.substack.com

• 📸 Twitter (X): @VipulSonule

• 🧑‍💼 LinkedIn: Vipul Sonule

• ✍️ Medium: Vipul Sonule