Reflected cross-site scripting (or XSS) arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.

Suppose a website has a search function which receives the user-supplied search term in a URL parameter:

https://insecure-website.com/search?term=gift

The application echoes the supplied search term in the response to this URL:

<p>You searched for: gift</p>

Assuming the application doesn't perform any other processing of the data, an attacker can construct an attack like this:

https://insecure-website.com/search?term=<script>/*+Bad+stuff+here...+*/</script>

This URL results in the following response:

<p>You searched for: <script>/* Bad stuff here... */</script></p>

If another user of the application requests the attacker's URL, then the script supplied by the attacker will execute in the victim user's browser, in the context of their session with the application.

👉 Attacker does NOT sit between you and server 👉 Instead, attacker tricks YOU into sending a bad request yourself

None
Web app pentesting

Real-World Attack Scenario

  1. Attacker creates a malicious link: https://bank.com/login?msg=<script>stealCookies()</script>
  2. Sends it via:
  • Email
  • WhatsApp
  • Fake website

3. User clicks the link

4. Website reflects the script → it runs in user's browser

5. Attacker steals session or performs actions as the user

Where Can We Put the Payload?

In reflected XSS, payloads can be injected anywhere the server takes input and reflects it back:

1. URL Parameters (most common)

?q=payload
?id=payload
?name=payload

2. Form Inputs

Example:

<formaction="/search">
<inputname="q">
</form>

If input is not sanitized → payload works.

3. HTTP Headers (less obvious but powerful)

Example:

  • User-Agent
  • Referer

If the server displays them somewhere (like logs or admin panel), payload can execute.

4. Path Variables

Example:

<https://example.com/profile/><script>alert(1)</script>

5. Hidden Fields / Query Strings in Redirects

Example:

<https://example.com/redirect?url=><script>alert(1)</script>

6. POST requests (hidden from URL)

👉 Happens in:

  • Login forms
  • Contact forms

Attacker can:

  • Create fake page
  • Auto-submit form behind the scenes

👉 You don't even see a "link"

SOMETIMES MAY ALSO POSSIBLE IN EMBEDDED REQUEST

<imgsrc="<https://site.com?q=><script>...</script>">

👉 Browser sends request automatically

7. AJAX / API requests

Modern sites (like Instagram) 👉 Data sent in background If reflected improperly → XSS possible

Reflected XSS in different contexts

When testing for reflected and stored XSS, a key task is to identify the XSS context:

  • The location within the response where attacker-controllable data appears.
  • Any input validation or other processing that is being performed on that data by the application.

Based on these details, you can then select one or more candidate XSS payloads, and test whether they are effective.

There are many different varieties of reflected cross-site scripting. The location of the reflected data within the application's response determines what type of payload is required to exploit it and might also affect the impact of the vulnerability.

In addition, if the application performs any validation or other processing on the submitted data before it is reflected, this will generally affect what kind of XSS payload is needed. BASE STRUCTURE :

[You / Attacker]
       ↓
   (HTTP Request)
       ↓
[Website Server]
       ↓
 (HTTP Response with injected code)
       ↓
[Victim Browser executes JS]
       ↓
[Attacker gets data]

Reflected XSS vs Self-XSS

✅ 1. Reflected XSS (Real attack) 👉 Attacker can trick victim using a link

🧪 Example: Attacker sends you this link:

<https://example.com/search?q=><script>alert(1)</script>

What happens:

  1. You click link
  2. Website reflects input
  3. Your browser runs the script
  4. 💥 Attack works automatically

👉 You didn't do anything except click

❗ 2. Self-XSS (Not a real direct attack) 👉 You must execute the code yourself

🧪 Example: Attacker tells you:

"Paste this in your browser console to get free coins"

alert(document.cookie)

What happens:

  1. You open browser console (F12)
  2. You paste code
  3. Script runs 👉 💥 But YOU ran it yourself

In a reflected XSS attack, the attacker typically crafts a malicious URL containing a payload and delivers it to the victim. The link might look something like:

http://actualwebsite.com/vulnerable_path?input=<malicious_payload>

The attacker hosts or distributes this link (for example, via their own exploit server, email, social media, or another delivery channel). When the victim clicks the link, the request is sent to the legitimate website, which then reflects the unsanitized input back in its response. If the payload is designed to execute automatically (for example, a script that runs on page load), the victim's browser executes it immediately.

While it's commonly said that reflected XSS requires tricking a user into clicking a malicious link — often via phishing emails — this is just the most typical scenario. In reality, attackers can deliver such links through many channels, including:

  • Social media posts or direct messages
  • Malicious advertisements (malvertising)
  • Compromised or injected links on trusted websites
  • URL shorteners or obfuscated links
  • Chat applications or forums

The key requirement is that the victim is induced to make a request containing the attacker-controlled input. Once that happens, the vulnerability in the target application does the rest by reflecting and executing the payload.

Impact of reflected XSS attacks

If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can:

  • Perform any action within the application that the user can perform.
  • View any information that the user is able to view.
  • Modify any information that the user is able to modify.
  • Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

13v! Bug Bounty Learner | H@ppie H@ck!nG