Cross-Site Scripting (XSS): Stored, Reflected & DOM-Based

Cross-Site Scripting (XSS) occurs when malicious JavaScript is injected into trusted web applications and executed by victims' browsers.

XSS Vulnerability Classes & Execution Contexts Matrix

The browser's HTML parser interprets text streams sequentially, building the Document Object Model (DOM). When the parser encounters characters like <, >, ", or ' in an unescaped context, it transitions into an execution state, treating incoming strings as HTML elements or JavaScript expressions.

Once an attacker successfully executes JavaScript in the victim's browser, they gain the full privileges of the authenticated user. Typical exploit payloads accomplish:

• Session Hijacking: Stealing session tokens stored in localStorage, sessionStorage, or accessible cookies (document.cookie).
• Credential Harvesting: Injecting fake login forms directly into the active webpage to capture passwords or MFA codes.
• Silent API Manipulation: Making background fetch() requests on behalf of the user to change email addresses, transfer funds, or generate API keys.
• Keylogging: Attaching event listeners (document.addEventListener('keydown')) to transmit keystrokes to an external server.

XSS vulnerabilities are classified into three primary types based on where the payload is stored and how it reaches the browser:

DOM-based XSS occurs entirely in the client-side JavaScript execution environment. An untrusted input (Source) flows into an execution function (Sink) without adequate sanitization.

Dangerous DOM Sources (Untrusted Input)

• location.search (URL query parameters)
• location.hash (URL fragments)
• document.referrer
• window.name
• postMessage() events without origin verification

Dangerous Execution Sinks

• element.innerHTML = untrustedData;
• element.outerHTML = untrustedData;
• document.write(untrustedData);
• eval(untrustedData);
• setTimeout(untrustedString, 100);
• location.href = untrustedUrl; (allows javascript:... pseudo-protocols!)

Safe DOM Alternatives

• Use element.textContent instead of element.innerHTML
• Use document.createElement() and element.setAttribute() instead of concatenating HTML strings

Modern frameworks like React automatically encode values rendered inside JSX curly braces ({userContent}), converting < to < and > to >. However, developers frequently bypass these protections:

1. `dangerouslySetInnerHTML` in React:

   // VULNERABLE: Bypasses React's automatic encoding
   <div dangerouslySetInnerHTML={{ __html: post.content }} />

1. URL Attribute Injection (`javascript:` URIs):

React does NOT validate URL protocols in anchor tags. If user-supplied input flows into href, attackers can submit javascript:alert(document.domain):

   // VULNERABLE if websiteUrl starts with 'javascript:'
   <a href={user.websiteUrl}>Visit Website</a>

1. Vue.js `v-html` Directive: Similar to React's dangerous HTML, v-html executes raw scripts if user content is passed un-sanitized.

Output encoding must match the exact context where data is inserted. Standard HTML entity encoding (<) is insufficient if data is placed inside an attribute or script tag:

• HTML Body Context: Convert & to &, < to <, > to >, " to ", ' to '.
• HTML Attribute Context: Inside <input value="...">, attributes must be attribute-encoded to prevent breaking out of quotes.
• JavaScript Variable Context: Inside <script>var x = '...';</script>, use JSON serialization with Unicode escaping (\u003C for <) to prevent script tag termination (</script>).
• URL Parameter Context: Use standard percent-encoding via encodeURIComponent().

When applications must accept rich text (e.g., Markdown or WYSIWYG HTML), sanitization must strip executable elements while preserving benign formatting tags (<b>, <i>, <p>). Use a battle-tested library like DOMPurify:

Content Security Policy (CSP) is an HTTP response header that restricts the resources (scripts, images, stylesheets, frames) the browser is allowed to load and execute. Even if an attacker injects an <script> tag into the DOM, a strict CSP prevents its execution.

Modern Nonce-Based CSP Policy

Modern CSP architectures use cryptographic random nonces generated per HTTP request:

The W3C Trusted Types API

Trusted Types locks down dangerous DOM sinks (like element.innerHTML and script.src) at the browser engine level. When enforced via CSP (Content-Security-Policy: require-trusted-types-for 'script'), the browser throws a runtime TypeError if plain strings are assigned to DOM sinks:

// Enforcing Trusted Types in Modern JavaScript
if (window.trustedTypes && trustedTypes.createPolicy) {
  const sanitizePolicy = trustedTypes.createPolicy('dompurify-policy', {
    createHTML: (input: string) => DOMPurify.sanitize(input),
  });

  // Browser accepts only TrustedHTML instances; rejects plain strings!
  const safeHTML = sanitizePolicy.createHTML(userComment);
  document.getElementById('content')!.innerHTML = safeHTML as unknown as string;
}

Next.js & React Auto-Escaping Gotchas

While React escapes strings rendered inside JSX expressions (<div>{userText}</div>), three dangerous escape hatches remain:

1. `dangerouslySetInnerHTML`: Bypasses React escaping entirely.
2. URL Attribute Protocol Injection: <a href={userLink}> executes JavaScript if the user submits javascript:alert(1).
3. SVG File Uploads: SVGs containing <script> tags execute arbitrary JavaScript when viewed directly in the browser.

Cross-site scripting (XSS) remains one of the most pervasive threats in modern web applications. Because client-side frameworks render dynamic DOM structures and bind to user state, static regex crawlers fail to catch complex DOM-based or stored XSS flaws.

How WeSecureX Detects Reflected, Stored, and DOM XSS

The WeSecureX Vulnerability Scanner executes automated dynamic audits using a headless browser sandbox:

1. Headless DOM Execution: WeSecureX renders your web pages in an instrumented Chromium environment. It hooks critical JavaScript sinks (innerHTML, document.write, eval, location.href) and monitors for payload execution in real time.
2. Context-Aware Payload Fuzzing: The engine injects safe, non-destructive test vectors specifically tailored to the injection context (HTML body, attribute strings, script blocks, or URI parameters) to confirm whether malicious tags like <svg/onload> execute.
3. Stored XSS Propagation Auditing: WeSecureX injects unique tracking markers into input fields (such as user profile names or comments) and crawls downstream views to verify whether the unescaped script tag executes when viewed by other users.
4. Content Security Policy (CSP) Efficacy Testing: The scanner evaluates whether your server's Content Security Policy successfully neutralizes inline script execution or if dangerous directives ('unsafe-inline', 'unsafe-eval') leave the application exposed.

Triage & Remediation in the Platform

When an XSS vulnerability is identified, WeSecureX registers the finding in your Vulnerabilities Dashboard with:

• Exact DOM stack trace showing the injection source and vulnerable sink.
• Step-by-step remediation guide recommending context-aware output encoding or DOMPurify integration.
• Automated re-testing capability to ensure your patch completely closes the exploit vector.

Launch a test using our Free Online XSS Scanner, verify headers with the Security Headers Checker, or read our guide on How to Triage False Positives in Vulnerability Scanning.