Reflected XSS (non-persistent cross-site scripting)

Reflected cross-site scripting is still one of the most common ways attackers exploit web applications: not by storing malicious code on a server, but by tricking users into executing it themselves. Typically delivered through phishing links or manipulated HTTP requests, reflected XSS executes in a single interaction, making it fast, targeted, and often difficult for users to recognize as a serious web security issue.

Unlike stored XSS, there is no persistence and the attack works only when a victim clicks a crafted malicious link or submits attacker-controlled input. That makes reflected XSS especially useful in social engineering campaigns, including those spread via email or social media, where attackers can combine technical exploitation with user deception.

What is reflected (non-persistent) XSS?

Reflected XSS is a type of cross-site scripting (XSS) where user-supplied input is immediately returned by a web application in its HTTP response without proper validation or encoding. If that input includes a malicious script (typically injected JavaScript code), the user’s browser executes the script as part of the web page.

The key difference compared to stored or persistent XSS is that the attack payload is not saved on the server. Instead, it is delivered in a request, usually as part of a URL or form submission, and the web server only reflects it back in its response. This makes reflected XSS a client-side attack, similar to DOM-based XSS. Client-side XSS can only affect users who directly interact with a malicious request, often via phishing or other forms of social engineering.

Reflected XSS vs stored XSS

Reflected XSS is often treated as a lower severity web vulnerability due to its reliance on user interaction, but it can still pose a significant security risk in specific cases.

Where reflected XSS still appears today

Reflected XSS is not limited to outdated applications. It continues to appear in modern systems, especially in areas where user input is quickly reused:

• Search results and filtering parameters
• Error messages and debug pages
• Redirect URLs and return parameters
• Legacy server-side rendering logic
• Improper handling of query parameters in frontend frameworks

These patterns are common in both traditional web apps and modern API-driven architectures, with XSS risk depending on the specific injection context. 

How reflected XSS attacks work

Most reflected XSS follows a common flow:

1. The attacker crafts a URL or request containing malicious input.
2. The victim clicks a crafted malicious link or otherwise submits the request.
3. The web application reflects the input in its response without proper encoding.
4. The victim’s browser executes the injected script in the context of the application.

Because the payload needs to be embedded in the request, attackers typically rely on delivery mechanisms such as phishing emails, chat messages, or malicious redirects to get users to trigger the attack.

A modern example of reflected XSS

To illustrate what makes reflected XSS possible, let’s look at a simple search feature in a Node.js application using Express:

app.get('/search', (req, res) => {
const query = req.query.q || '';
res.send(`<h1>Search results for: ${query}</h1>`);
});

What makes this code vulnerable to XSS

The vulnerable web application takes user input from the q parameter and directly injects it into the HTML response without validation or encoding. This allows attackers to inject HTML tags and executable code into the page. To take advantage of this, an attacker can craft the following URL:

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

Note that this example uses plain tags for clarity, but real XSS payloads are usually URL-encoded to evade filters that check for special characters. The encoded version would look like this:

https://example.com/search?q=%3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E

When a victim clicks this link, the server directly passes on the q parameter value and responds with:

<h1>Search results for: <script>alert('XSS')</script></h1>

The browser interprets the <script> tag and executes the JavaScript within it. In this case, the input is inserted directly into HTML content, but the exact risk depends on where user input is placed in the page.

What a real attacker can do with a cross-site scripting vulnerability

While simple tests and examples like this one use alert() to pop up a harmless alert box, real cross-site scripting attacks with malicious JavaScript can be far more serious. Using reflected XSS as part of a full attack chain, a hacker might be able to:

• Steal session tokens such as session cookies to impersonate the user (unless cookies are protected with HttpOnly).
• Capture form inputs and other sensitive data, including credentials.
• Redirect the user to a malicious site.
• Perform actions on behalf of the user within the application, potentially hijacking the user’s session.

Because the script runs in the trusted context of the vulnerable application, it has access to everything the user can access in their web browser.

How to fix and prevent reflected XSS vulnerabilities

The root cause of reflected XSS is unsafe handling of untrusted input. In practice, the safest approach is to avoid manual string handling and rely on frameworks and libraries that handle output encoding correctly as part of your mitigation strategy.

1. Use frameworks or templating engines with auto-escaping

The most reliable way to prevent XSS is to avoid constructing HTML manually. Modern frameworks and templating engines can escape user input by default. For example, instead of building HTML strings directly, you can use:

res.render('search', { query: req.query.q || '' });

Templating engines such as EJS and Handlebars or frontend frameworks like React automatically encode output in most cases, as long as unsafe rendering features are avoided. This alone can greatly reduce the risk of XSS.

2. Use a trusted encoding library

If you need to construct HTML manually, use a well-tested encoding library rather than writing your own logic, for example:

const he = require('he');

app.get('/search', (req, res) => {
const query = he.encode(req.query.q || '');
res.send(`<h1>Search results for: ${query}</h1>`);
});

If an attacker supplies a payload like <script>alert('XSS')</script>, the response gets encoded to:

<h1>Search results for: &lt;script&gt;alert(&#39;XSS&#39;)&lt;/script&gt;</h1>

The browser now safely renders the input as text instead of executing it.

3. Understand how output encoding works

At a basic level, output encoding replaces special characters with safe equivalents so they are not interpreted as code. A conceptual escaping function may look like this:

const escapeHtml = (str = '') =>
str.replace(/[&<>"']/g, (char) => ({
  '&': '&amp;',
  '<': '&lt;',
  '>': '&gt;',
  '"': '&quot;',
  "'": '&#39;',
}[char]));

In practice, you should rely primarily on established libraries or framework functions rather than implementing your own encoding logic, since correct handling depends on context and includes edge cases that are easy to miss and hard to update.

4. Apply context-sensitive encoding

Encoding must match where the data is used. HTML body encoding is different from encoding inside attributes, JavaScript, or URLs. Using the wrong encoding can still leave exploitable gaps, which is another reason to rely primarily on frameworks or libraries that handle context automatically.

5. Apply defense-in-depth controls

Additional controls can reduce the impact of XSS if a vulnerability is missed or a new attack vector is exploited:

• Use a Content Security Policy (CSP) to restrict which scripts can execute.
• Mark session cookies as HttpOnly to prevent JavaScript access.
• Use secure headers to limit browser-side risks.
• Consider additional protections such as web application firewalls (WAFs).
• Perform input validation and sanitization as an additional layer of protection, but don’t rely on them alone for XSS prevention.

6. Continuously test running applications

Because reflected XSS appears in live responses, dynamic application security testing is particularly effective at detecting it. Modern DAST tools identify reflection points, inject payloads, and analyze responses to confirm exploitability, making them essential for penetration testing and continuous security validation.

DAST on the Invicti Platform extends this with proof-based scanning to automatically validate many critical vulnerabilities and confirm they are exploitable. For reflected XSS, Invicti DAST reports can include a one-click proof of concept to demonstrate the attack. This level of confidence lets teams focus on real, exploitable issues and reduce time spent on false positives.

To see how Invicti DAST can identify XSS and hundreds of other vulnerability types in your application environments, you can request a demo of the Invicti Platform.