September 9, 2026

Cross-Site Scripting (XSS): Bug Bounty Technical Report

Focus: Web Security • Red Team • Bug Bounty

By Rifdhyrm

5 min read

1. Executive Summary

Cross-Site Scripting (XSS) remains one of the most important web application vulnerabilities. It occurs when attacker-controlled input reaches a browser and is interpreted as executable HTML or JavaScript.

XSS can appear in search fields, profiles, comments, support tickets, error pages, APIs, file uploads, and modern JavaScript applications.

The most important lesson is simple:

Don't start with payloads. Start by understanding where your input is rendered.

The impact depends heavily on context and the user who eventually views the vulnerable content.

2. The Three Main Types of XSS

2.1 Reflected XSS

Reflected XSS occurs when malicious input is immediately returned in an HTTP response without appropriate encoding.

A simple example:

/search?q=<test>

If the application places the value directly into HTML without encoding it, the input may become executable markup.

Common locations include:

  • Search parameters
  • Error messages
  • Redirect parameters
  • URL paths
  • Filter parameters
  • Custom headers

For authorized testing, a harmless proof of execution such as:

<img src=x onerror=alert(document.domain)>

can demonstrate that attacker-controlled HTML reached an executable context.

2.2 Stored XSS

Stored XSS is more serious because the payload is saved by the application and later rendered to other users.

Common targets include:

  • User profiles
  • Comments
  • Support tickets
  • Forum posts
  • Reviews
  • Rich-text editors
  • Administrative dashboards
  • File metadata

For example, imagine a support system storing:

Message: <test>

If an internal support dashboard later renders that value as HTML without proper protection, the stored input may execute whenever an employee opens the ticket.

The important question is not simply "Can JavaScript execute?"

It is:

Who will execute it?

An XSS affecting an administrator or privileged support user can have substantially greater impact than one affecting only the attacker's own account.

2.3 DOM-Based XSS

DOM XSS occurs primarily in client-side JavaScript.

The server may return the page normally, but JavaScript takes attacker-controlled data and writes it into an unsafe browser sink.

Typical sources include:

  • location.search
  • location.hash
  • document.URL
  • postMessage
  • localStorage

Common dangerous sinks include:

  • innerHTML
  • outerHTML
  • document.write()
  • eval()
  • insertAdjacentHTML()
  • React dangerouslySetInnerHTML

A simplified vulnerable pattern looks like:

element.innerHTML = location.hash;

A safer approach is to treat the value as text:

element.textContent = location.hash;

The key methodology is source → transformation → sink tracing.

3. Context-First XSS Testing

One of the biggest mistakes in XSS testing is trying hundreds of payloads without understanding the rendering context.

First determine where your input appears.

ContextExampleHTML body<div>INPUT</div>Attribute<input value="INPUT">JavaScript stringvar x = 'INPUT';URL<a href="INPUT">CSSstyle="color:INPUT"

Then choose a payload appropriate for that context.

For example, if the application produces:

<div>INPUT</div>

you are testing an HTML context.

If it produces:

<input value="INPUT">

you must determine whether quotes are encoded and whether you can safely demonstrate breaking out of the attribute.

This context-first approach is much more efficient than blindly spraying payload lists.

4. Simple XSS Proofs

For authorized testing and labs, keep the initial proof simple.

HTML context

<img src=x onerror=alert(document.domain)>

SVG context

<svg onload=alert(document.domain)>

Attribute context

Test whether quotation marks are correctly encoded before attempting a controlled breakout.

DOM context

Trace whether attacker-controlled URL data reaches an unsafe sink.

The goal of the first test is confirmation, not maximum exploitation.

Avoid collecting real credentials, session tokens, or personal information.

5. Useful XSS Tooling

You don't need to publish hundreds of lines of scripts to explain a practical workflow. These projects already provide mature tooling.

Burp Suite

Use Burp Suite to:

  • Intercept requests
  • Modify parameters
  • Replay requests
  • Compare responses
  • Identify reflection points
  • Investigate rendering behavior

PortSwigger Web Security Academy XSS Labs

Dalfox

Dalfox is a popular open-source XSS scanner designed for parameter analysis and automated testing.

Dalfox on GitHub

A simple workflow is:

URLs → Parameter discovery → Reflection testing → Manual validation

Automated results should always be manually verified.

Nuclei

Nuclei can be useful for repeatable security checks and template-based scanning.

Nuclei Templates on GitHub

Use scanning tools to reduce repetitive work, not as a replacement for understanding the application's behavior.

Semgrep

For source-code review, Semgrep can help identify potentially dangerous JavaScript and framework patterns.

Semgrep Security Rules

A useful workflow is:

Source → Find user-controlled data → Trace transformations → Inspect sink → Validate

6. CSP Analysis

Content Security Policy (CSP) is an important defense-in-depth control, but it should not be treated as a replacement for correct output encoding.

Look for the application's:

Content-Security-Policy

Important directives include:

  • script-src
  • object-src
  • base-uri
  • frame-ancestors

For example:

script-src 'self'

is generally stronger than allowing unrestricted inline scripts.

Weak policies may contain dangerous allowances such as:

'unsafe-inline'

or:

'unsafe-eval'

The correct approach is to fix the underlying XSS vulnerability first and use CSP as an additional security layer.

7. Reporting XSS Professionally

A strong bug bounty report should be short, reproducible, and focused on impact.

Title

Stored XSS in support-ticket message rendered in employee dashboard

Summary

Explain where attacker-controlled input is stored and where it is later rendered.

Steps to Reproduce

  1. Log in using a test account.
  2. Submit a harmless XSS proof.
  3. Open the affected page.
  4. Observe controlled JavaScript execution.

Impact

Explain who can be affected and what privileges that user has.

Evidence

Include:

  • Request/response
  • Screenshot
  • Affected URL
  • Rendered HTML
  • CSP header
  • Redacted Burp evidence

Remediation

Recommend context-aware output encoding and appropriate sanitization where HTML is intentionally supported.

8. Responsible Impact Demonstration

A vulnerability report should prove the security issue without creating unnecessary risk.

For example:

alert(document.domain)

can demonstrate JavaScript execution without stealing information.

For blind XSS testing, use a unique canary identifier such as:

XSS-CANARY-001

rather than attempting to collect real cookies or credentials.

In bug bounty programs:

  • Don't access other users' sensitive data.
  • Don't steal production session tokens.
  • Don't modify production records.
  • Don't create persistent payloads that harm real users.
  • Follow the program's rules of engagement.

For red-team engagements, use controlled accounts and environments unless the authorization explicitly permits production testing.

9. Remediation

9.1 Context-Aware Output Encoding

Encode untrusted data according to its output context.

HTML, attributes, JavaScript, CSS, and URLs require different handling.

The safest default is:

Treat untrusted input as data, not executable code.

9.2 HTML Sanitization

If an application genuinely needs to support user-controlled HTML, use a well-maintained sanitizer with an appropriate allowlist.

DOMPurify on GitHub

Sanitization should be part of a defense-in-depth strategy, not an excuse to skip proper output encoding.

9.3 Safe DOM APIs

Prefer APIs that treat content as text.

Safer:

element.textContent = userInput;

Riskier:

element.innerHTML = userInput;

Avoid unnecessary use of dynamic code execution such as eval() and similar APIs.

Session cookies should generally use appropriate security attributes, including:

HttpOnly
Secure
SameSite

These controls don't fix XSS, but they can reduce the impact of some attacks.

10. Practical XSS Testing Roadmap

A simple workflow for authorized assessments:

1. Map the application
        ↓
2. Identify user-controlled inputs
        ↓
3. Find reflection/storage points
        ↓
4. Determine rendering context
        ↓
5. Test with harmless canaries
        ↓
6. Trace DOM source → sink flows
        ↓
7. Review CSP and browser protections
        ↓
8. Validate impact safely
        ↓
9. Document reproducible evidence
        ↓
10. Recommend remediation

This methodology is more valuable than memorizing thousands of payloads.

11. GitHub Resources

For readers who want to continue practicing:

These resources provide labs, detection techniques, defensive guidance, and practical examples.

12. Key Takeaways

  1. Understand the context before choosing a payload.
  2. Reflected, stored, and DOM XSS require different investigation strategies.
  3. Stored XSS severity depends heavily on who renders the content.
  4. Modern applications require source-to-sink DOM analysis.
  5. Burp Suite, Dalfox, Nuclei, and Semgrep can accelerate testing.
  6. CSP is defense-in-depth, not a substitute for fixing XSS.
  7. Use harmless canaries and controlled accounts when demonstrating impact.
  8. A concise, reproducible report is more valuable than a huge payload list.

The goal of professional XSS testing isn't to find the longest payload. It's to understand the data flow, prove the vulnerability, demonstrate realistic impact safely, and explain exactly how to fix it.

Rifdhy RM….