If you are learning web security, Cross-Site Scripting (XSS) is one of the most important vulnerabilities to understand. At first, XSS can seem complicated because it involves browsers, HTML, JavaScript, user input, requests, and responses. But the core idea is actually simple: XSS happens when an application allows untrusted user input to be interpreted by the browser as executable code or markup. Let's understand this step by step. What is XSS? XSS stands for Cross-Site Scripting. It is a web application vulnerability where an attacker is able to inject content—often JavaScript—into a web page in a way that causes the victim's browser to interpret it as code. The important part is not simply that someone entered JavaScript. The real problem is: Untrusted Input ↓ Application handles it unsafely ↓ Browser interprets it as HTML/JavaScript ↓ Code executes in the application's context So, in simple words: The application was supposed to treat the attacker's input as data, but the browser ended up treating it as code. That is the fundamental idea behind XSS. A Simple Example Imagine a website has a comment section. A normal user submits: Hello everyone! The application might generate HTML like: HTML

Hello everyone!

The browser sees this and displays: Hello everyone! Everything is normal. Now imagine the application takes user-controlled content and inserts it directly into the page's HTML without handling it safely. For example, conceptually: element.innerHTML = userInput; Here, userInput is controlled by the user. The important issue is that innerHTML doesn't simply treat its value as plain text. It parses the value as HTML. Therefore, if an attacker manages to place HTML/script-capable content into that location, the browser may interpret it as markup rather than ordinary text. That's where XSS can occur. Why Does the Browser Matter? The browser is extremely important in XSS. A simplified web request looks like this: User ↓ Browser ↓ Web Application ↓ Server ↓ HTML Response ↓ Browser ↓ HTML is parsed ↓ JavaScript may execute The server sends a response, and the browser interprets that response. If attacker-controlled data becomes part of the HTML/DOM in an unsafe context, the browser may interpret that data as something other than plain text. That's the fundamental mechanism behind many XSS vulnerabilities. What Is "Untrusted Input"? Untrusted input means data that comes from a source that the application should not automatically trust. For example: Search fields Comments Usernames Profile information Form fields URL parameters Some HTTP headers Data stored in a database Content controlled by another user Consider this URL: https://example.com/search?q=hello The value: hello is controlled by the user. The application might take it and display: HTML

Search results for hello

That can be perfectly safe if handled correctly. But if the application places attacker-controlled input into an unsafe HTML context, it can potentially lead to XSS. XSS Is Not Just "Someone Entered JavaScript" This is an important point. A common beginner misconception is: "If I enter JavaScript into a website, it is XSS." No. Simply entering JavaScript doesn't automatically mean an XSS vulnerability exists. For XSS to occur, the application must handle the input in a way that allows it to reach an executable or markup-interpreting context. For example: element.textContent = userInput; and: element.innerHTML = userInput; behave very differently. textContent is intended to treat the value as text. innerHTML parses the value as HTML. So the context in which the input is placed matters enormously. The Core XSS Concept: Data vs Code This is probably the most important concept to understand in Part 1. Suppose a user enters: The application may want to display exactly that as text: But if the application places it into an HTML-parsing context without appropriate protection, the browser may interpret as HTML markup. In other words: What the application intended:

DATA ↓ "some input"

What can go wrong:

DATA ↓ HTML/Code ↓ Browser interpretation So XSS is fundamentally about breaking the boundary between data and executable/markup content. What Can XSS Do? The impact depends heavily on the application's functionality and security controls. Successful XSS can potentially allow an attacker to: Modify content displayed on the page Create fake UI elements Perform actions in the victim's browser context Steal or expose sensitive information that is accessible to JavaScript Perform phishing-style attacks Interact with the application as the victim Abuse the application's functionality However, one important misconception should be cleared up: XSS does not automatically mean that an attacker can steal cookies. Modern applications can use protections such as: HttpOnly Secure Content Security Policy (CSP) Proper output encoding These can significantly change what an attacker can accomplish. The Three Main Types of XSS XSS is commonly divided into three major categories.

1. Reflected XSS The malicious input comes through a request and is reflected back in the application's response. Simplified flow: Attacker Input ↓ Request ↓ Server ↓ Response ↓ Victim's Browser For example, an application might use a search parameter: /search?q=hello If the application takes q and places it unsafely into the response, Reflected XSS may be possible.
2. Stored XSS In Stored XSS, attacker-controlled content is stored by the application. For example: Attacker ↓ Comment ↓ Database ↓ Application ↓ Victim ↓ Browser Imagine a vulnerable comment system. An attacker submits malicious content as a comment. The application stores it in the database. Later, another user opens the comments page. If the application renders that stored content unsafely, the attack can execute in the victim's browser. This is why Stored XSS can be particularly serious: the attacker may not need to directly send a specially crafted request to every victim.
3. DOM-Based XSS DOM-based XSS is primarily related to client-side JavaScript and DOM manipulation. For example, imagine client-side code does something conceptually like: element.innerHTML = location.search; Here, browser-controlled data is being placed directly into an HTML-parsing sink. The simplified flow is: Browser Input ↓ Client-Side JavaScript ↓ DOM Manipulation ↓ Unsafe HTML Interpretation ↓ XSS Unlike traditional reflected XSS, the vulnerable behavior can exist entirely in the browser-side code. The Three Types in One Table Type Basic Flow Reflected XSS Request → Server → Response → Browser Stored XSS Input → Storage → Victim → Browser DOM-Based XSS Browser Input → JavaScript → DOM → Browser Don't worry if these three aren't completely clear yet. We'll study each one in much more detail in later parts. A Simple XSS Formula You can remember the basic concept like this: Untrusted Input

Unsafe Handling + Browser Interpretation ↓ XSS But remember: Untrusted input by itself is not XSS. An application can safely handle untrusted input through appropriate context-sensitive defenses. What We Learned After Part 1, you should understand these concepts: XSS = Cross-Site Scripting XSS occurs when untrusted input reaches a context where the browser can interpret it as executable code or markup. The browser plays a central role because it interprets HTML and executes JavaScript. User-controlled input is not automatically dangerous; how the application handles it is critical. XSS has three major categories: Reflected XSS Stored XSS DOM-Based XSS The distinction between data and code is the foundation of understanding XSS. HTML-parsing APIs such as innerHTML can become dangerous when used with untrusted input. The one sentence you should remember: XSS is fundamentally about allowing attacker-controlled data to cross into a context where the browser interprets it as code or markup. Part 2 → XSS Source, Flow & Sink: How attacker input travels through a web application and exactly where XSS gets triggered.