Web Security Series #10 — Exploiting DOM-Based Cross-Site Scripting (XSS)

Web Security Series #10 — Exploiting DOM-Based Cross-Site Scripting (XSS) | by Laibakashif - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original Web Security Series #10 — Exploiting DOM-Based Cross-Site Scripting (XSS) Introduction Laibakashif Follow ~6 min read · March 26, 2026 (Updated: March 26, 2026) · Free: Yes Introduction Cross-Site Scripting (XSS) is one of the most common and impactful vulnerabilities found in modern web applications. It occurs when an application fails to properly handle user-supplied input, allowing attackers to inject malicious JavaScript that executes in another user's browser. Among the different forms of XSS, DOM-Based XSS is particularly interesting because the vulnerability exists entirely on the client side , without direct involvement from the server. In this lab, I demonstrate how user input is rendered directly into the webpage's DOM, how basic payloads behave in such an environment, and how attackers can ultimately execute JavaScript to manipulate user actions. Understanding Cross-Site Scripting (XSS) Definition Cross-Site Scripting (XSS) is a web security vulnerability where an attacker injects malicious JavaScript into a web application, causing it to execute within the browser of another user. If exploited successfully, XSS can allow attackers to: Execute arbitrary JavaScript Steal session cookies Redirect users to malicious websites Modify webpage content Perform actions on behalf of the victim Types of XSS Stored XSS The malicious payload is stored in the application's database and executed whenever the affected page loads. Reflected XSS The payload is sent in a request and immediately reflected back in the response from the server. DOM-Based XSS The vulnerability exists entirely on the client side where JavaScript dynamically processes and inserts user input into the DOM without proper validation. When to Test for XSS Testing for XSS is important when: User input is rendered back onto the page without sanitization Client-side JavaScript modifies or updates the DOM Applications rely heavily on dynamic content User-controlled data is inserted directly into HTML elements DOM-Based XSS is typically identified when: ✔ The payload appears in the page ✔ No request is sent to the server ✔ The vulnerability occurs purely in the browser Objective of the Lab The goal of this lab is to: Understand how DOM-based XSS works Test different JavaScript payloads Observe how the application handles injected HTML Identify why some payloads fail while others succeed Demonstrate how attackers can trigger actions using XSS Lab Behavior and Analysis This lab provides a Todo List application where users can add tasks that appear instantly on the page. When analyzing the application using: Ctrl + Shift + C → Network Tab → Reload We observe: No request is sent to the server No server response is received All processing happens locally in the browser This confirms that the application is vulnerable to: DOM-Based XSS The client-side JavaScript inserts user input directly into the DOM without proper validation or sanitization. Lab Interface Exploitation Process Step 1 — Adding Normal Inputs To understand the application behavior, I first added two normal todo items: Drink water Wash scooty These items appear instantly in the todo list, confirming that user input is rendered directly into the page. Step 2 — Testing a Basic XSS Payload Initial payload used: Observed Behavior The payload appears in the list The script does not execute The browser treats the script tag as text This suggests that the application is likely using a method similar to: .innerText or another approach that escapes