Thursday, November 24th, 2005

Cross-Domain Ajax. Security Implications in Depth

Category: Security

Joe Walker has joined a discussion on Cross Domain XHR.

He talks about the areas of concern:

  • Resource Theft: Resource theft can happen when Jack Innocent visits the website of Evil Bob. Evil Bob has written some XHR code that repeatedly requests compute expensive pages from the site of Victim Inc. Thus Evil Bob gets to use Jack Innocent to do his nasty work.
  • Cross Site Scripting: Should we ban cross-domain XHR because of XSS attacks? I’m not sure, but be sure of this: there are plenty of ways to allow XSS attacks on your site without cross-domain XHR.
  • Slow 3rd Party Web Sites: If you design your website to use thousands of small requests then you are asking for trouble – so don’t do it! Likewise if you design your website to depend on a slow resource then expect your website to be slow. Eric is right in saying that proxy caching is a great solution to this problem, but let’s not ban cross-domain XHR because people can do silly things with it.

I am personally waiting for trusted domains. It would be great to be able to say “ trusts and”.

The server side could have a say in the matter too. If you want to offer your web service to the world to do whatever they want, then you should be able to say “let anyone talk to me”

What do you all think?

Should we open this all up?

Posted by Dion Almaer at 2:01 am

3.1 rating from 9 votes


Comments feed

Absolutely not, because of the intranet theft problem – which is the reason JavaScript (in the time before Ajax) has a same-domain policy enforced for code involving frames in the first place.

Say I work for, and when I’m hooked up to their network at work I can access a private intranet at Without the cross-domain restriction an attacker could add some code to their page which silently retrieves and posts it back to their site using XHR.

Comment by Simon Willison — November 24, 2005

Resource theft can be done anyway with DOM manipulation or even (new Image()).src = “URL”, so you might as well strike that off the list.

Intranet theft is a real issue, but if your intranet used HTTP authentication on your intranet, like you obviously should, then there is no problem.

Slow websites are slow websites.. we can already do that. XHR actually lets you mitigate it by controlling when things get loaded and it gives you the opportunity to deal with timeouts and slow resources on a case by case basis.

Comment by Bob Ippolito — November 24, 2005

Flash addresses this issue with the crossdomain.xml policy file. A crossdomain.xml file on a server specifies who (by domain) can access what resources. For example, Apple keeps their content locked down…

… while Yahoo! opens up their APIs to the world…

I think this approach works well for everyone.


Comment by Christian Cantrell — November 24, 2005

Flash’s crossdomain is a rather silly approach to the problem, but I’m all for it if that’s what it takes to get the browser developers and security community to allow web developers to do cross-domain services.

I think that’s unlikely, though.

Comment by Bob Ippolito — November 25, 2005

Bob, if you’re going to call it silly, can you at least explain why? If you have some ideas, I’d love to hear them. I’ve always thought of Flash’s security model as an excellent solution.


Comment by Christian Cantrell — November 28, 2005

I disagree with almost all of your conclusions and would love to discuss further.

Comment by Lucas Carlson — February 10, 2006

I can’t help think that Lucas’ article dodges the problem by defining AJAX as “good things that people do with XMLHTTPRequest.” I’d leave that comment there (as well as some more concrete points), but unfortunately, comments have been closed on that entry, so I can’t.

As Simon and others point out, there are lots of bad things that can if you open up the security model on XMLHTTPRequest. They may not be “AJAX” (whatever that is), but they’re serious concerns regardless.

Comment by Mark Nottingham — February 15, 2006

Leave a comment

You must be logged in to post a comment.