"Wait… how can a website attack me from inside itself?"

Hey guys — today we're talking about one of the most important and misunderstood web vulnerabilities: Cross-Site Scripting (XSS).

At first glance, XSS sounds simple: an attacker injects JavaScript into a web page. But the real danger isn't just "running a script." The real danger is where that script runs.

When XSS works, the malicious code runs inside the same origin as the vulnerable website. That means the browser treats it as trusted — and that's how attackers bypass the Same-Origin Policy (SOP).

Let's break that down.

None

What is the Same-Origin Policy, and why does XSS break it?

The Same-Origin Policy (SOP) is one of the browser's core security rules.

It says: A script from one website should not be able to access data from another website.

So:

  • A random site can't read your bank cookies.
  • A malicious ad can't manipulate your email session.
  • One origin cannot touch another origin's data.

An "origin" is defined by:

  • Protocol (http/https)
  • Hostname (example.com)
  • Port (80, 443, etc.)

Normally, this keeps the web safe.

But with XSS, the attacker's script is injected into the vulnerable site itself. From the browser's point of view, it looks like part of the website's own code.

So SOP no longer protects the user — because the attack is now "coming from inside the house."

Why XSS is so dangerous

Once an attacker has JavaScript execution inside a trusted origin, they can:

  • Read session cookies.
  • Perform actions as the user.
  • Modify page content.
  • Redirect users to malicious pages.
  • Steal tokens, credentials, or personal data.

In simple terms: XSS gives attackers control over the victim's browser session.

That's why XSS is not a "small bug." It's a full client-side compromise.

Why JavaScript matters for XSS

XSS is a client-side attack, which means it runs in the user's browser — not on the server.

So if you want to understand XSS properly, you need basic JavaScript knowledge.

Also, different browsers interpret JavaScript slightly differently. A payload that works in Chrome might not behave the same in Firefox or Safari. That's why real-world testing always matters.

How to experiment with JavaScript in your browser

You can open your browser's developer console:

  • Firefox: Ctrl + Shift + K
  • Chrome: Ctrl + Shift + J
  • Safari: Command + Option + J

Once the console is open, try these basics:

1. Displaying a popup

alert(1)
alert("XSS")

This is the classic XSS test. If you see an alert, you know JavaScript executed.

2. Logging data to the console

console.log(1)
console.log("test text")

This helps you debug payloads and see what data is accessible.

3. Encoding and decoding data

btoa("test")      // Encode to Base64
atob("dGVzdA==")  // Decode from Base64

Attackers use encoding to hide payloads, bypass filters, or remove special characters.

4. Accessing sensitive data

alert(document.cookie)

This shows exactly why XSS is dangerous. If cookies aren't protected properly, attackers can steal session tokens and hijack accounts.

The three main types of XSS

Let's recap the three major categories.

1. Reflected XSS

This happens when user input is reflected directly in the response.

Example:

  • You search for something.
  • The site displays your search term.
  • The attacker injects a script into that input.
  • The victim clicks a crafted link and the script executes.

This type often relies on social engineering but is very common.

2. Stored XSS

This happens when user input is stored in a database and later shown to others.

Example:

  • Comments, reviews, usernames, profile bios.
  • The attacker injects a script.
  • Every user who views that content executes the script automatically.

Stored XSS is usually the most dangerous because it spreads silently.

3. DOM-based XSS

This happens entirely on the client side.

Example:

  • The page reads data from the URL or user input.
  • JavaScript inserts it into the DOM unsafely.
  • No server reflection or storage is needed.

This type is common in modern JavaScript-heavy apps and can be harder to detect.

The big picture

None

XSS is not just "a pop-up bug."

It:

  • Breaks browser trust boundaries.
  • Bypasses the Same-Origin Policy.
  • Gives attackers control over user sessions.
  • Turns a website into an attack platform against its own users.

Once you understand XSS, you start seeing the web differently — not as pages, but as execution contexts and trust boundaries.

And that's where real security thinking begins.