JSON: Or why this love affair may soon end

JSON. It promises much. Using native browser Javascript parsing, the client can magically operate on data retrieved from the server with a trivial eval function call.

Using <script src="..."/> to pull down data from another domain, something XMLHttpRequest cannot do.

JSON, as you all know, is an acronym for JavaScript Object Notation. Objects are not just data. They contain functions too. So not only can I bring down data, I can bring down additional functionality. Which, if you think about it, it pretty cool.

But external JSON extremely dangerous. We are talking about arbitrary third-party code that is executed in the context of the running web page. That means any data available in the current scope is free game to that new functionality.

What can happen? Passwords might be stored in the current scope. Any data from other domains, including the original, can be scraped. Any of this data can be sent back to the third-party server. Clearly, this is an enourmous security risk, and trusting a thrid-party is not enough. Controls need to be put in place.

Can XMLHttpRequest be updated to include third-party domains? The Flash player has a nice model, albeit proprietary. They can afford many luxuries since they own the complete running client. A well-known XML document sits in a site root named "crossdomain.xml". Pretty self-explanatory at this point. Host A's XML contains entries of valid third-party domains, Host B and Host C, so that when Flash is served up from from B and C, and client Flash accesses resources on A, the Flash player first accesses the crossdomain.xml to check if the originating host (B or C) has A's permission.

One may respond that I can return XML as a JSON string and parse using the browser's DOM API. Yeah, but doesn't this all seem like a hack, a temporary fix for the larger problem. And it may work fine for a while, but we can do better!