Reflected XSS Lab: Make a Search Box Run Your JavaScript

This article explains reflected cross-site scripting (XSS) through a practical lab where users inject JavaScript into a BookShop search box that returns unsanitized user input as HTML. Reflected XSS is the most reported web vulnerability in bug bounty programs, and understanding how it works is critical for both attackers and defenders. The lab demonstrates why input should never be inserted into a page as markup, and covers real-world attack patterns and defenses.

• How reflected XSS exploits unsanitized outputThe BookShop search page uses innerHTML to insert the user's search term directly into the page heading without escaping special characters. When a user searches for HTML markup instead of text, the browser interprets angle brackets as real tags and executes any embedded code with the site's full permissions. This happens because the browser cannot distinguish between markup the developer wrote and markup that came from the attacker's input.
• Why script tags fail but event handlers succeedBrowsers deliberately block script elements added through innerHTML as a built-in safety measure, so a simple `` injection will not work in this lab. However, event-handler attributes on HTML elements bypass this protection. An attacker can inject an image tag with a broken source that triggers an error handler containing JavaScript, which executes with the site's permissions when the load fails.
• Attack payloads differ by injection contextThe lab demonstrates that successful exploitation requires first identifying where user input lands in the page's HTML structure. Input can land inside a tag, inside an attribute, or inside JavaScript code, and each context requires a different payload construction approach. Testing with harmless markup first—like bold tags—helps confirm the injection point before attempting functional exploits.
• Real-world consequences of reflected XSSAttackers use reflected XSS to steal session data, perform actions as the victim, or display convincing fake login forms on the legitimate domain. Because the attacker's script runs with the site's full trust, it can read the page content, act as a logged-in user, and send sensitive data to external servers. This makes reflected XSS particularly dangerous for phishing and credential theft.
• Defenses require multiple layersThe article lists four key mitigation strategies: HTML-encoding user input before insertion, using safe DOM APIs like textContent instead of innerHTML, relying on frameworks like React and Vue that escape by default, and adding a Content Security Policy to block inline scripts and event handlers. The article explicitly warns that blocklists filtering the word 'script' are ineffective because attackers have dozens of alternative injection methods.
• Reflected versus stored XSS distinctionReflected XSS requires an attacker to send the victim a crafted link containing the payload in the URL, and the attack only affects that specific victim's browser. Stored XSS is saved by the server and runs for all users who view the affected page, making it more dangerous at scale. The lab focuses on reflected XSS because it represents the most common vulnerability reported in bug bounties.
• XSS ranks as top critical weaknessCross-site scripting appears as CWE-79 at the top of MITRE's 2024 CWE Top 25 list of the most dangerous software weaknesses and consistently ranks among the most reported bug classes on bug bounty platforms. This consistent prominence underscores why hands-on understanding of XSS mechanics is essential for cybersecurity professionals.

Bottom line: Reflected XSS exploits occur when user input is inserted into HTML as markup rather than text, allowing attackers to inject functional JavaScript that runs with the site's permissions. The fundamental defense is to always escape user input for its context, prefer safe APIs like textContent over innerHTML, and implement Content Security Policy as a secondary protection layer.