What is the rationale behind AJAX cross-domain security?

Question

Given the simplicity of writing a server side proxy that fetches data across domains, I'm at a loss as to what the initial intention was in preventing client side AJAX from making calls across domains. I'm not asking for speculation, I'm looking for documentation from the language designers (or people close to them) for what they thought they were doing, other than simply creating a mild inconvenience for developers.

TIA

Answer 1

It's to prevent that a browser acts as a reverse proxy . Suppose you are browsing http://www.evil.com from a PC at your office, and suppose that in that office exists an intranet with sensitive information at http://intranet.company.com which is only accessible from the local network. If the cross domain policy wouldn't exists, www.evil.com could made ajax requests to http://intranet.company.com , using your browser as a reverse proxy , and send that information to www.evil.com with another Ajax request.

This one of the reasons of the restriction I guess.

Answer 2

The most important reason for this limit is a security concern: should JSON request make browser serve and accept cookies or security credentials with request to another domain? It is not a concern with server-side proxy, because it don't have direct access to client environment. There was a proposal for safe sanitized JSON-specific request methods , but it wasn't implemented anywhere yet.

Answer 3

If you're the author for myblog.com and you make an XHR to facebook.com, should the request send your facebook cookie credentials? No, that would mean that you could request users' private facebook information from your blog.

If you create a proxy service to do it, your proxy can't access the facebook cookies.

You may also be questioning why JSONP is OK. The reason is that you're loading a script you didn't write, so unless facebook's script decides to send you the information from their JS code, you won't have access to it

Answer 4

The difference between direct access and a proxy are cookies and other security relevant identification/verification information which are absolutely restricted to one origin.

With those, your browser can access sensitive data. Your proxy won't, as it does not know the user's login data.

Therefore, the proxy is only applicable to public data; as is CORS .

Answer 5

I know you are asking for experts' answers, I'm just a neophyte, and this is my opinion to why the server side proxy is not a proper final solution:

• Building a server side proxy is not as easy as not build it at all.
• Not always is possible like in a Third Party JS widget . You are not gonna ask all your publisher to declare a DNS register for integrate your widget. And modify the document.domain of his pages with the colateral issues.
• As I read in the book Third Party Javascript "it requires loading an intermediary tunnel file before it can make cross-domain requests" . At least you put JSONP in the game with more tricky juggling.
• Not supported by IE8, also from the above book: "IE8 has a rather odd bug that prevents a top-level domain from communicating with its subdomain even when they both opt into a common domain namespace" .
• There are several security matters as people have explained in other answers, even more than them, you can check the chapter 4.3.2 Message exchange using subdomain proxies of the above book.

And the most important for me:

• It is a hack.. like the JSONP solution, it's time for an standard, reliable, secure, clean and confortable solution.

But, after re-read your question, I think I still didn't answer it, so Why this AJAX security? , again I think, the answer is:

Because you don't want any web page you visit to be able to make calls from your desktop to any computer or server into your office's intranet