Wednesday, July 26th, 2006

Why XHR should support Cross Domain

Category: Articles

<p>Peter Nixey has written a piece on his frustrations with the lack of cross domain XHR in his current applications.

Clientside cross-domain data requests are an extremely useful tool. They can only currently be done (in Javascript) using the script-tag workaround to deliver data as JSON.

External JSON is extremely dangerous as it is arbitrary third-party code executed in the scope of the current web-page. It can be used to steal passwords or data present in the current scope. JSON is also a non-generalised data standard and requires new server-side libraries and code.

XML is already a data standard in wide use with API’s present in most programming languages. It’s inert, human-readable and highly compressible using gzip.

Any cross domain XHR must be server opt-in (rather than opt-out) or else we leave all non-enabled servers vulnerable to brute-force attacks.

Agreement can very simply be communicated by having the server send a header authorising cross-domain use of the data.

… any thoughts?

Related Content:

  • Ajax worm can hijack Web sites
    It's incredibly easy to create a worm using Ajax that controls all the communication between a user and the server, according to expert Anurag...

Posted by Dion Almaer at 9:39 am

3.5 rating from 24 votes


Comments feed TrackBack URI

Why not just XHR to a PHP/ASP script that parses/sends data to the remote server and returns the feedback, effectively like a proxy for remote-domain communications.

I’ve been doing it for ages, it’s not exactly difficult.

You can easily create cross-domain authentication systems by just using a shared authentication DB (accessible by both domains), a timeout mechanism and a unique ID.

You can effectively do a secure XHR between domains with authentication like this… as long as you can do some basic PHP/ASP/etc and have a shared authentication DB that both domains can access.

Comment by method — July 26, 2006

External JSON is only dangerous if you eval it. The json library does have a parser .. I’d recommend using it for external or untrusted content.

Comment by Sam Foster — July 26, 2006

Well, you *can* do a brute-force attack now, too. Just add elements to the page. You *can* execute dangerous remote code. Just add elements to the page. There is no reason to limit XHR to the same domain.

Yes, proxying data is easy. But what about if you have to proxy it for 1.000.000 people? It needs an expensive server park. Compare it to a lightweight server.

Comment by András Bártházi — July 26, 2006

I make it work anyway with a bunch of hacks. So what is the point in blocking it? It will just make it easier for companies like mine that want to display data on a remote partner web site.

Comment by Phill Kenoyer — July 26, 2006

External JSON is only dangerous if you eval it. The json library does have a parser .. I’d recommend using it for external or untrusted content.

That would be a good idea, if it were at all possible. But it isn’t, for cross-domain JSON. You have to use the script tag, which essentially means you’re evaling the JSON response.

Comment by Michael Geary — July 26, 2006

Method, you can of course use the proxy approach and this is exactly what I did when I was building eventsites. There is almost always a workaround for something but it doesn’t mean that it shouldn’t be implemented.

A good language is as efficient and empowering as possible and good design should address issues at the most appropriate level of abstraction.

XHR is not a finalised standard yet and if it can be, the cross-domain issue should be dealt with in its specification rather than in what will cumulatively total thousands of man-hours of hacks.

As Michael pointed out, there is no opportunity to parse cross-domain JSON, it has to be immediately eval’d and therein lies the danger.

That aside though, why reinvent the wheel. XML already offers the tools and the security required, why not simply make it accessible cross-domain rather than trying to force JSON into a hole it wasn’t meant to fit.

There’s nothing to stop JSON being served within an XML packet I simply propose that as an existing and powerful standard, XML should be the transport.

Comment by Peter Nixey — July 27, 2006

I wrote a solution to this that just uses script tags to get JSON data from external domains:

Cross-Domain JSON without XHR

Comment by Jesse Skinner — August 11, 2006

i want to display page contents from one remote to another remote. how can i display it.

Comment by Naveen kumar sharma — October 5, 2006

Leave a comment

You must be logged in to post a comment.