As I understand it, the basic idea of XSS is to let the user's browser execute some malicious code created by the hackers.

Say, if a page has a vulnerability of loading arbitrary script when user access this URL:


Then the browser will load the malicious.js file without any question, and the user will be hacked.

My question is, how do hackers make the user access such an URL?

As in the case above and all other techniques like it, all have one precondition: the user has to take some action that they wouldn't usually take.

If the hacker has to come to say "hi, there is something funny, take a look!" to everyone, that won't be a very effective attack.

So, are there any tricks to make this happen automatically? Or any real-life cases that cause this?

  • 7
    "... the user did some actions that they won't do as usual..." - like, clicking on a link on some web site or in a mail? Or maybe just the usual visit to the same website as before in case of stored XSS. That's all what is needed. Commented Sep 19, 2018 at 6:05
  • 61
    You might also want to check this question which has some more details about XSS in general.
    – Christoph
    Commented Sep 19, 2018 at 7:47
  • 1
    @Christoph Stole my line!
    – aroth
    Commented Sep 19, 2018 at 15:27
  • 11
    @Christoph I actually clicked that link without even reading the link... I'm too trusting of this site, I should really be more careful even on trusted sites... Commented Sep 20, 2018 at 8:24
  • 1
    @Christoph just to put a more p̶a̶r̶a̶n̶o̶i̶d̶ careful spin, though - if the comment was upvoted by bots (or a lot of malicious users?), then it'd give people a false sense of security. Well, this site will probably stop false voting but then again, what if it was Facebook or other social media and somebody posts a malicious link then it gets Liked (through fake accounts) a lot - it also seems safe. And the website is unlikely to be as fast to deal with it as this one.
    – VLAZ
    Commented Sep 21, 2018 at 6:18

7 Answers 7


the user did some actions that they won't do as usual

Clicking on a link does seem like a usual action for most users.

See for example this study, in which 56% of users clicked on links in E-Mails from an unknown sender, and ~40% clicked on links send via Facebook (despite 78% being aware of the possible danger). 50% said that they didn't click the link because they didn't know the sender.

That's already an impressive success rate. If the victim knows the attacker, or if the attacker spoofs the identity of someone they know, this rate could be increased even further.

On social networks, reflected XSS might also be wormable. In addition to the malicious action, the injected script could send messages containing the link to all friends of the victim (something like this eg happened to Twitter).

In addition to E-Mail, links could also be distributed in forums, blogs, issue trackers, and so on. This for example happened to Apache.

  • Thanks for reply tim. If the hacker decided to using email to start attack, he/she must have the ability of send tons of email to a large number of victims. and this is easily been identified and mark as spam by email system, and so does the social networks isn't it? Commented Sep 19, 2018 at 8:08
  • In an ideal system it would be flagged and often it actually is. But with mail addresses which grow older, you get more and more spam which comes through the filters (as you get more spam in total) and some providers have better filters than others. So sending bulk mail does still work in 2018 for many spammers, scammers and phishers.
    – allo
    Commented Sep 19, 2018 at 8:21
  • @HetfieldJoe Ideally mass emails would be caught, but not necessarily. It really depends on the specifics. You might be attacking the users of a relatively small site, so you don't send out that many mails (I would assume that this is the norm; sure, it might happen that you find and want to exploit a reflected XSS issue in say google, and thus need to send out millions of mails; but more often, I would expect a smaller userbase). You might also only target privileged users of a site to gain those privileges.
    – tim
    Commented Sep 19, 2018 at 8:38
  • 36
    I kind of expected the "this study" link in the answer to point to some malicious (looking) URL. That would have been hilarious …
    – CL.
    Commented Sep 19, 2018 at 9:08
  • 1
    @HetfieldJoe: Developers constantly need to have the ability to send tons of email to large numbers of people simply to implement things like user registration systems (Facebook, Google, Uber, AirBnB etc.) and order confirmation systems (Aliexpress, Amazon, Apple, Bloomthis etc.). Simply sending thousands of emails per day (my previous employer sent 30k emails per day) does not mean you're spamming. Spam algorithms look at content rather than number of emails and content can be made to be crafted to look like order confirmation form online stores.
    – slebetman
    Commented Sep 20, 2018 at 5:02

That's what I've always wondered as well, and when asking I was usually told that "users don't take care and click everything". Which said that way makes it sound like reflected XSS isn't really a vulnerability of software, but a vulnerability of users. All this sounded strange to me because I'm the kind of person who usually checks the link preview (hovering with the mouse on the link in the browser), and if somebody tells me to click on this question on StackExchange and I spot the weird format (see the path), I am not going to click.

However I have to say that there are ways to make reflected XSS more dangerous than it seems at first. Consider the following points:

  • Automatic clicks, redirects, or similar tricks: you don't have to click, all you have to do is land on a malicious website that will redirect automatically to the target website and execute the malicious javascript. If you are logged in on the target website, the attacker will make you execute arbitrary javascript and perform malicious actions (send or delete stuff, etc.)
  • Websites that typically have long or complex URLs (not user-friendly) and that the user tends to trust anyway. I tend to see this on Amazon, the links are unreadable anyway.
  • Browsers that don't let you see a preview easily, like on mobile browsers or other software where it's not as simple as just hovering. I have to admit that I don't take the time to verify links on mobile, I just tap, although on mobile I only try to use a restricted selection of trusted websites.
  • The attacker knows the victim, knows how to convince them to click on a link or visit a page, and the victim in some cases might even trust the attacker. A random email from a total stranger is not the same as a Facebook private message from a (malicious) acquaintance.
  • Boobs and lols: pictures with boobs, lolcats, etc. can make you lose your consciousness temporarily, and you might feel like you have to click on it at once like it's a law of physics.

So as you can see the risks associated with reflected XSS can vary a lot, depending on the user, the trust given to the affected website, the possible actions on the target website, etc. Nevertheless it still remains a software vulnerability in any case, because by definition it allows arbitrary javascript execution by exploiting a weakness in input sanitization.


The example you have given is very trivial. There are plenty of applications that have dozens of GET parameters in the URL being shared. All the attacker needs is for one of these to be vulnerable to reflected XSS in order for this to succeed. If the link someone is expecting is long and complex, and what they get is long and complex, then they may not look into each parameter.

Also, they could use a URL shortener.


There are two main types of XSS, Reflective and persistent. Persistent XSS is when it is stored on the server, affecting other users, while reflective is not stored, but can still affect other users.

One method I've seen is to store something like a redirect is in a comment that has poor sanitising. This way, the code is stored server-side, and when someone requests the page, the code is loaded along with the comments, which then triggers the block of code. This can then redirect the victim to the attackers website, where other malicious things could be occurring, e.g. Fake login pages for credential harvesters, stacks of ads, etc.

If you need more info let me know, I can edit when I'm back at the PC and add more details.

EDIT: For example, if a site was susceptible to this type of attack, a comment could be left that redirected all users that visited that page to a new site, this new site could be a near identical copy of the original site, designed to get you to log in again, and then steal credentials. Because people tend to use the same passwords on multiple sites, these credentials could then be used to log in elsewhere, etc.


  • 2
    Thanks, Connor J. I understand the power of Persistent XSS. and the sites nowadays are pretty much well sanitized. It's very hard (to me) to spot a point to inject code. If only the vulnerability mentioned above exists, how could it been used? Commented Sep 19, 2018 at 7:59
  • 1
    @HetfieldJoe I think OWASP might disagree. XSS is still #7 on their Top 10, so apparently most sites aren't as well sanitized as you might think. Browse owasp.org/index.php/Cross-site_Scripting_(XSS), or since you probably shouldn't trust links in messages anyway, head to the OWASP page and search for XSS. They have a good bit of information about all sorts of security issues in websites, including how easy it is to redirect to other content.
    – Shawn
    Commented Sep 20, 2018 at 20:22
  • Just to add to @Shawn's excellent point, XSS has been on the OWASP top 10 since 2003, where it was at #4, found here , so it is extremely prevalent
    – Connor J
    Commented Sep 21, 2018 at 8:14
  • @ConnorJ And sadly, if you look at the last several Top 10s (and the SANS 25), there hasn't really been a whole lot of movement on many of the items, especially XSS and Injection issues.
    – Shawn
    Commented Sep 21, 2018 at 13:38

Any time a web developer does this:

<script src="someOtherDomainThanThisOne"></script>

That is a possible avenue for XSS. The site the user is visiting does not need to be compromised in the least, only the site hosting the script.

For example, if I'm a web developer working on my website widgets.com and I find this flashy new js library. Instead of hosting it directly from my site, I chose the unsecure path of including it (via script src) from cooljslibs.com. At some point in the future, either cooljslibs.com goes rogue, or someone hacks it and compromises the hosted files. Now, widgets.com has not been hacked in any way, but because it's blindly running code from cooljslibs.com it has compromised it's users and site.

This can be partially mitigated using subresource Integrity, which basically is forcing a hash check on the 3rd party file. It's still best to host it yourself in addition to this. You can learn more about it here. ex:)

<script src="https://example.com/example-framework.js"

I think one great example of how a XSS can be used in the wild is the recent British Airways data breach. As explained in this article: https://www.riskiq.com/blog/labs/magecart-british-airways-breach/ the attackers stored a malicious javascript, replacing a usual script on the payment page, that would steal the user entered credit card. Although this is not a typical XSS attack since they had an access to the server to change the script, it is still a very valid demonstration of such an attack.

If you can store in some way some valid javascript on a website (stored XSS), you can then steal the user's cookie and impersonate that user and access the same information (like profile data).

As for reflected XSS, you do need to make some social engineering and make the user click on a malicious link as others have pointed out.


For some attacks the victim needs to visit the attacker's page. There are a couple of ways to do that:

  • Phishing. Send the victim an email, Facebook page, LinkedIn invitation with a link pretending to be something else. The success rate of this depends on how much effort goes into the campaign, but success rates above 50% are not uncommon. Especially because the domain name matches: you try to trick users of somegoodsite.com to click on a somegoodsite.com link, and this can generally be trusted.
  • Inclusion from within the site itself. Sometimes the site permits to add user content. If the attacker can add an iframe to their profile page, anyone who accesses their profile will be attacked. However, it is pretty uncommon to be able to add an iframe to any site.
  • Man-in-the-middle attack. In a man-in-the-middle attack the attacker can modify unencrypted data. Even if somegoodsite.com uses HTTPS, the attacker can inject an iframe in a webpage that doesn't use HTTPS and cause your browser to visit the URL.
  • Advertisements. Some sites run intrusive advertisements that load a page in an iframe or even a new window. I sometimes get these with the message that I have won a free iPhone, but you could also run them with an XSS payload. However, I think sites that allow advertisements this intrusive are pretty rare.
  • Thanks for reply Sjoerd. as you said, in case of Phishing, Advertisements or UI redress the success of hacker depends on his effort on marketing, the problem to him is shifted even higher level, into a seems non-technical area. That make me confused on how they did it. Commented Sep 19, 2018 at 8:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .