XSS — Reflected

First, four words you will keep hearing

• ●A website talks to your browser using HTTP.
• ●A page is written in HTML.
• ●Some HTML can run JavaScript.
• ●When you log in, the site stores a cookie that proves who you are. That logged in state is your session.

Hold those four ideas. Everything below is just them interacting. Ready? Let's go.

How It Works

Reflected XSS is a chain of six dominoes. Knock the first, the rest fall on their own.

Attacker
   |
   v
Builds a link with a hidden <script> inside a parameter
   |
   v
Sends the link to a victim  ==>  email, chat, ad, QR code
   |
   v
Victim clicks  ==>  the REAL, trusted website opens
   |
   v
Website copies the parameter back into the page (forgets to escape it)
   |
   v
Browser cannot tell content from code  ==>  it RUNS the script
   |
   v
Script runs AS the website  ==>  steals the cookie or acts as the victim

Notice domino number four. That single missing step, escaping the input, is the whole bug. The other five are just delivery and consequence.

Visual Explanation

Same website, two inputs. Watch how the browser reacts to each.

SAFE INPUT
User       :  types "laptop"
Website    :  shows  Results for laptop
Browser    :  prints text   ==>  nothing bad happens

ATTACK INPUT
Attacker   :  sends  <script>steal()</script>
Website    :  shows  Results for <script>steal()</script>
Browser    :  sees a real script tag  ==>  RUNS it   ==>  you are owned

And here is the data flow of a full attack, left to right:

Attacker  ==>  Victim   ==>  Application  ==>  Victim Browser  ==>  Attacker Server
(crafts)      (clicks)      (reflects)        (executes JS)        (receives cookie)

Attack Flow

Let me tell it the way the attacker lives it. First person. You are the attacker now.

You are poking at AnasTech. You open their portal and search for `laptop`. The page replies: *Results for laptop*. Interesting. It is repeating my word.

So you search for something weird: `<b>laptop</b>`. The page now shows the word in bold. Your heart rate ticks up. The site is not just repeating text, it is treating your input as HTML.

You try `<script>alert(1)</script>`. A little popup says `1`. That popup is proof: you just ran your own code inside their website, in their visitor's browser.

Now you stop playing and start working. You swap the popup for a line that grabs the visitor's cookie and sends it to your server. You wrap it in a normal looking link, shorten it, and email it to Sarah in accounting as *"Your invoice is ready"*.

She clicks at 9:14 AM. The real portal opens. Nothing looks wrong to her. But your script already ran, read her session cookie, and shipped it to you. You paste that cookie into your browser and the portal greets you as Sarah. No password. No malware. Just one reflected parameter and one click.

Definition

Simple version: the site takes something from your link and prints it back on the page. If it forgets to neutralise it, your *something* can be code that runs in the victim's browser.

Technical version: untrusted input from the HTTP request (a query parameter, a form field, a header) is reflected into the HTTP response without escaping, so an attacker can inject script that executes in the victim's browser inside the site's own origin.

Why it matters: because the code runs *as the trusted site*, it inherits that site's powers, reading cookies, reading the page, and making requests as the logged in user.

Commonly affected: search boxes, error and 404 pages, login pages that echo a username, marketing links with tracking parameters, and any old endpoint that says *"you searched for X"*.

Why Developers Make This Mistake

Nobody writes this bug on purpose. It sneaks in for very human reasons.

• ●It feels harmless. *"It is just a search box, who would attack a search box?"* So escaping gets skipped.
• ●String glue is easy. Writing `"Hello " + name` is faster than reaching for a templating engine that escapes for you.
• ●They tested with normal input. `laptop` looks perfect on screen, so the code ships. Nobody typed `<script>`.
• ●They trusted the wrong layer. They validated on the page with JavaScript, but the server still reflected raw input.
• ●Output context is invisible. The same value is safe as text but dangerous inside an attribute or a script tag, and that nuance is easy to miss.

Beginner Summary

If you only remember five things, remember these. Thirty seconds, then you get it.

• ●The website repeats your input back, and forgets to make it safe.
• ●You hide JavaScript in a link parameter.
• ●The victim clicks the link on the real, trusted site.
• ●Their browser runs your code as if the site wrote it.
• ●You steal their cookie or act as them. No password needed.

Reflected vs Stored vs DOM

XSS has three cousins. This lesson is the first one. Know the difference so you never mix them up.