Reflected XSS

What Is Reflected XSS?

Reflected cross-site scripting hides in the URL. Nothing is planted on the server: one crafted link runs the attacker's script on your own origin, inside the victim's logged-in session. You'll replace a store's search term with an img onerror payload and watch the results heading execute it. Then you open the search handler, find the query concatenated into the response HTML, escape it at the rendering boundary, and replay the same payload as inert text. A blocklist hunting for script tags never sees this one.

What You'll Learn in Reflected XSS

• Distinguish Reflected XSS from Stored XSS: the URL is the delivery channel, and each victim must open the attacker's crafted link
• Spot the reflection point in a URL-to-HTML response pipeline by reading the handler code
• Apply HTML escaping at the rendering boundary as the primary defense, not WAF blocklists or input sanitization
• Understand why an img onerror payload executes even without a script tag, and why blocklists that target script tags fail
• Recognize that shipping the fix neutralizes execution, not delivery: the phishing link still exists

Reflected XSS — Training Steps

1. Find the store search

   Today Bob is targeting Vellora , an online marketplace with a large base of logged-in customers. He opens the public store search to see how it behaves. A search box that echoes your query back into the page is the first thing an attacker probes.

2. Run a normal search

   First, see how the feature behaves for a real shopper. Run an ordinary product search. The store returns matching items, and the term Bob typed is repeated back inside the results heading.

3. The query is reflected

   The exact term Bob searched comes straight back inside the results heading, and the address bar now carries it as a q parameter. That reflection is only dangerous if the page fails to escape the value on the way out. The only way to know is to feed it a character the browser treats as markup.

4. Test whether it escapes

   Bob probes the reflection with a classic test: an image tag with a broken source and an onerror handler that pops a harmless alert(1) . If the page escapes the query, this shows up as plain text in the heading. If it does not, the browser builds a real tag and the alert fires.

5. It is exploitable

   The alert fired. The page does not escape the query, so it runs whatever markup the URL carries. That harmless alert(1) was only the confirmation. A real payload does not pop a dialog, it runs silently and steals the visitor's session cookie.

6. Weaponize and phish

   Bob swaps the alert for a cookie-stealer that beacons the session to his own server, wraps it in a Vellora search link so it runs on the trusted store domain, and hides it behind a friendly reward. Then he mails it to a real employee whose session is worth stealing: Alice. People trust links to their own company's store.

7. A reward, out of nowhere

   A reward email lands in your inbox. It looks like it is from Vellora, and the button points at the store you use every day. Nothing obviously wrong.

8. Claim the reward

   The link opens Vellora's own store, so it feels safe. Click through to claim the reward.

9. What the link actually ran

   The page is just Vellora's search, showing a broken image where the results heading should be. But the link's q parameter carried a script. It ran the instant the page rendered, read your session cookie, and beaconed it to the attacker. There was no popup. The broken image is the only trace.

10. Your session is hijacked

    Minutes later, security operations flags it. The link you opened turned your own storefront against you, and now someone else is holding your session. The hijacked page is still open beside the alert. You own this code. Read the alert, then go fix the root cause.