Cross-Site Scripting (XSS)

Introduction

Cross-Site Scripting (XSS) is a web security vulnerability that allows an attacker to inject malicious code, usually JavaScript, into a web page viewed by other users.

The vulnerability happens when an application takes untrusted input and includes it in a page without properly encoding or sanitizing it first. When the browser receives the response, it treats the malicious code as legitimate content coming from the trusted website and executes it.

Depending on the application, XSS can be used to steal session cookies, impersonate users, modify page content, or perform actions on behalf of the victim.

---

Reflected XSS

Reflected XSS happens when user input is immediately returned in the server response without proper encoding.

A common example is a search page.

Request

/search?q=laptop

Response

You searched for: laptop

If the application simply prints the value without encoding it, an attacker could send:

/search?q=<script>alert('XSS')</script>

The browser receives:

You searched for: <script>alert('XSS')</script>

and executes the script.

Reflected XSS usually requires the victim to click a specially crafted link sent through email, chat, or social media.

---

Stored XSS

Stored XSS occurs when malicious input is saved by the application and later displayed to other users.

Common targets include comment sections, user profiles, forums, support tickets, and chat applications.

For example, an attacker submits:

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

The application stores the value in the database.

Every user who later views the page receives the malicious script and executes it automatically.

Stored XSS is generally more dangerous than reflected XSS because the payload remains in the application and can affect many users without requiring them to click a malicious link.

---

DOM XSS (Client-Side XSS)

The DOM (Document Object Model) is the browser's internal representation of a web page. JavaScript uses the DOM to read, modify, and update page content after the page loads.

DOM XSS happens entirely in the browser. Instead of the server injecting the payload, client-side JavaScript reads untrusted data and inserts it into the page in an unsafe way.

Example:

document.getElementById("result").innerHTML = location.hash.substring(1);

If a user visits:

https://example.com/#<img src=x onerror=alert('XSS')>

the browser inserts the payload into the page and executes it.

In this case, the server may never even see the attack because everything happens on the client side.

---

How to Determine Whether Your Application Is Vulnerable

Security testing tools such as OWASP ZAP can help identify potential XSS issues, but manual code review is still one of the most effective ways to find vulnerabilities.

---

How to Protect Your Application

Most XSS vulnerabilities can be prevented by following simple principles.

1. Encode Output

Never render raw user input directly into HTML.

Instead of allowing:

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

Render:

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

The browser displays it as text instead of executing it.

2. Sanitize HTML When HTML Is Allowed

Some applications intentionally allow rich text formatting. In those cases, use a trusted HTML sanitizer such as OWASP Java HTML Sanitizer before displaying the content.

---

Don't Modern Frameworks Protect Against XSS?

In many cases, yes.

Modern frameworks such as Spring Boot applications automatically escape HTML when rendering user-provided data in templates. Characters like < and > are converted into safe HTML entities before reaching the browser.

For example, if a user submits:

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

the framework typically renders it as plain text rather than executable code.

However, these protections only work when developers use the framework correctly. XSS vulnerabilities usually appear when developers bypass template escaping, render raw HTML, or manually inject untrusted data into the page.

A simple rule to remember:
Frameworks help prevent XSS, but they do not eliminate the need to treat user input as untrusted data.