Home / Knowledge hub / Reflected XSS
Knowledge hub
Reflected XSS
A script in a link that your page echoes straight back into the response.
What it means
Reflected XSS is cross-site scripting where the malicious script arrives in the request and is copied straight into the response. A search page that prints "You searched for ..." without encoding the text is the textbook case. The payload is not saved anywhere.
The attacker builds a link with the script in a parameter and gets someone to open it, by email, chat or a message on social media. The browser sees the script as coming from your site, so it runs with your origin's rights and the visitor's session.
Why it matters
The bug needs a victim to click, but that is rarely a barrier. A convincing link in a phishing email is enough, and it points to your real domain, so it passes a quick glance. Once the script runs it can read the page, call your API as that visitor and change what they see.
Customers and partners tend to be the targets, not your staff. A reflected flaw on a sign-in or password-reset page is the worst place for it, because the script can capture credentials. Scanners find simple cases of it, so unfixed ones are easy for others to find as well.
How it shows up
You meet it in search results, error pages, redirect and status messages, form re-display after a failed validation, and any page that prints a URL parameter. Look at where the parameter lands: HTML body, attribute, script block or URL each need different encoding.
Typical mistakes are encoding for the wrong context, filtering a list of bad words that an attacker works around, and fixing one parameter while another on the same page remains. Encode on output for the exact place the value is written, and test with a real browser rather than by reading the response text.
Questions people ask
Reflected XSS, answered
Does the victim have to click a link?
Yes, or load it some other way, such as through a redirect or an embedded frame. The payload is in the request, so something has to send that request from the victim's browser.
Is reflected XSS less serious than stored XSS?
It needs a victim to act, so it is harder to exploit at scale. But the impact once it runs is the same, and a good phishing link makes it practical against targeted people.
Do browsers block reflected XSS automatically?
Older browsers had a built-in filter, and modern ones have removed it. Do not count on the browser. Encode output and use a content security policy.
Can POST requests be reflected XSS?
Yes. An attacker can host a page with an auto-submitting form that sends the payload by POST. The delivery is different, the bug is the same.
How do we test for it?
Put a harmless marker in each parameter and see where it comes back. Then try a payload that suits the context and confirm in a browser that it ran.
Related
Terms that sit next to this one
XSS
An attacker's script running in your pages, in your customers' sessions.
Stored XSS
Malicious script saved by your app and then served to other people who view it.
DOM-based XSS
Script injection that happens in the browser's own code, not in the server's response.
Output encoding
Escaping data for its destination so it is shown as text, not run as code.
Phishing
Persuading someone to hand over credentials by posing as a trusted sender.
Does your page repeat what it is sent?
We try parameters across your pages and report a reflected XSS only if the script ran in a browser, with the request, the response and a screenshot. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.