Understanding XSS — Part 2: Reflected XSS, Deep Dive

This is Part 2 of an 8-part series on Cross-Site Scripting (XSS). Part 1 covered the fundamentals — what XSS is and why it happens. Here, we look at the first and most common type: Reflected XSS. What Makes XSS "Reflected" Reflected XSS is called reflected because the malicious input isn't stored anywhere on the server. It travels along with the request, the server immediately echoes it back in the response, and the browser executes it — all within a single request-response cycle. Nothing persists. Send the same crafted request tomorrow, get the same result; never send it, and the page behaves normally for everyone else. The defining trait: the payload has to be part of the request that triggers it. Why It Needs a Victim to Click Something Since the payload rides along in the request, the attacker isn't the one who ends up visiting the malicious link — the victim is. That makes reflected XSS as much a delivery problem as a technical one. Common ways it reaches a victim: Phishing emails or messages with a link to the vulnerable site Malicious ads or forum posts linking to a legitimate, trusted domain — which makes the link far more convincing than a link to an unknown site URL shorteners, used to hide a suspicious-looking link inside a clean one Shared or indexed links that unsuspecting users click through Why the Victim Usually Needs to Be Logged In The injected script runs in the victim's browser, inside the security context of whatever site is vulnerable. If the goal is stealing a session, that only matters if the victim has an active session on that site at the time. This is why reflected XSS is often paired with pretexts tied to something the victim is already doing on that site — increasing the odds they're logged in when they click. The Limitation That Defines It Reflected XSS has one major constraint: it requires a fresh interaction every time. There's no payload sitting on the server waiting for the next visitor — each victim has to individually click a crafted link. That makes it: Harder to scale automatically than stored attacks Dependent on how convincing the delivery is Mitigable at the point of click, not just at the code level That single limitation is exactly what the next type in this series removes. What's Coming Next Part 3 covers Stored XSS — what happens when the payload doesn't need a crafted link at all, because the application saves it and serves it to every visitor automatically.