Reflected XSS

Craft a reflected XSS URL that fires the moment a victim opens it, then ship the HTML-escape fix at the render boundary.

What Is Reflected XSS?

Reflected XSS is the kind of cross-site scripting that hides in the URL itself. The attacker never plants anything on the server; they wrap a crafted URL in a phishing email, a chat link, or an ad, and the moment the victim opens it their browser executes the script. This exercise puts you on both sides. As Bob, a financially motivated attacker, you find the store search at Vellora, an online marketplace, and notice it reflects the URL query parameter straight back into the results heading. You swap the search term for an img onerror payload, watch it run in the browser, and see how the same value wrapped in a link would fire in any logged-in customer's session. As Alice, Vellora's application security engineer, you walk into an overnight escalation (customers clicked a shared search link and had their sessions hijacked), reproduce the reflection first-hand, open the search handler, and find the query concatenated straight into the response HTML. You apply the fix at the rendering boundary, escaping the value before it joins the response, then replay the attacker's exact payload against the patched build and watch it come back as inert text. The exercise closes with quiz questions on how Reflected differs from Stored XSS, why the crafted link executes on the store's own trusted origin, and why output encoding at the render boundary is the right primary control.

What You'll Learn in Reflected XSS

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.