Dashboard

Security Sandbox & Interactive Demonstrations

Interactive Labs

Learn, Simulate & Mitigate Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) is a critical class of web security vulnerability where an application includes untrusted data in a web page without proper validation or escaping. This allows attackers to execute malicious scripts in the context of a victim's browser session. Explore each vulnerability tab to test payloads, view vulnerable code, and examine secure solutions.

Core XSS Vulnerabilities Covered

📡

Reflected XSS

Input from an HTTP request (like query parameters) is immediately returned by the server and rendered onto the page without sanitization. Typically executed via crafted links sent to victims.

💾

Stored XSS

The injected script is permanently saved on the server (like in a database or file). It is later served to other users visiting the affected pages, leading to wide-scale execution.

🌐

DOM-based XSS

The vulnerability exists entirely in client-side script logic. Unsafe inputs (like URL hashes or query strings) are written directly into execution sinks (like innerHTML) by frontend code.

Status: Loading...

Reflected XSS Sandbox

Submit a search query. The server echoes whatever you search for. In vulnerable mode, scripts inside the search will execute in the browser.

Exploit Payloads
Output Rendering Sandbox Vulnerable

Code & Prevention Deep-Dive

Toggle the Sandbox Security switch at the top to compare vulnerable and secure server implementations.

Server-Side Route Implementation
server.js
Status: Loading...

Stored XSS Guestbook

Write comments to the guestbook wall. These comments are stored in the server's in-memory database. In vulnerable mode, scripts stored here run for anyone viewing the guestbook.

Exploit Payloads

Guestbook Wall

Vulnerable

Code Comparison - Stored XSS Mitigation

Toggle the security switch at the top to see the difference between raw interpolation and dynamic text nodes.

Client-Side Rendering logic
app.js

Prevention Strategy Checklist

  • ✓
    Output Encoding: Avoid using dynamic HTML builders like element.innerHTML with raw variables. Instead, use textContent or innerText which automatically escapes characters.
  • ✓
    Data Sanitization: If rendering user-authored rich text is necessary, pass input through a validated library (like DOMPurify) to strip scripting tags and events while keeping safe elements.
Status: Loading...

DOM-based XSS (Theme customizer)

DOM-based XSS occurs when frontend script logic reads a user-controlled source (like the URL hash) and processes it unsafely inside a DOM sink (like innerHTML) entirely in the browser.

Simulated Browser Address Bar
http:// localhost:3000/#theme= default
Exploit Payloads

Active Theme Dashboard

Vulnerable

This panel responds dynamically to theme configuration variables parsed from the URL.

Active: Default Theme

Styles parsed from local URL context.

Code Comparison - DOM XSS Prevention

Toggle the protection switch to compare direct string interpolation with dynamic property assignments and allowlists.

Client-Side JavaScript Implementation
app.js

Safe Client DOM Handling

  • ✓
    Avoid Dangerous Sinks: Avoid writing raw user strings to elements with innerHTML, outerHTML, or executing them directly via eval() or document.write().
  • ✓
    Strict Allowlists: Filter user input against a known set of safe parameters (e.g. ['dark', 'light', 'cyberpunk', 'retro']) before executing DOM updates.

Universal XSS Defense in Depth

Modern applications prevent XSS by combining context-aware output encoding, input sanitization, and server-side sandboxing rules like Content Security Policy (CSP).

1. Context-Aware Output Encoding

Always encode user input before rendering it. The encoding method depends on where the data is placed inside the HTML document:

  • ✓
    HTML Body Context: Convert characters like <, >, and & into HTML entities.
  • ✓
    HTML Attribute Context: Escape quotes and spaces to prevent attackers from breaking out of attributes.
  • ✓
    JavaScript Context: Parse dynamic variables inside JSON block structures rather than injecting inline text.
Standard HTML Escaper Function
function escapeHTML(str) {
  return str
    .replace(/&/g, '&amp;')
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;')
    .replace(/"/g, '&quot;')
    .replace(/'/g, '&#x27;')
    .replace(/\//g, '&#x2F;');
}

2. Content Security Policy (CSP)

CSP is an HTTP response header that dictates which resources (scripts, stylesheets, images) the browser is permitted to load, serving as a powerful mitigation filter against script injections.

Default Policy (Vulnerable)
Allows inline scripts and third-party remote scripts to execute.
No CSP
Strict Policy (Protected)
Blocks all inline script injection blocks. Requires cryptographically signed nonces or local hashes.
CSP Active
  • ✓
    default-src 'self' restricts network calls to the current host origin.
  • ✓
    script-src 'self' blocks any script blocks written in raw HTML templates, neutralizing simple XSS.