I’ve always thought that the JSON hack was a truly weird happenstance. For those who don’t quite know it, it goes something like this. A web page you download can run limited code inside your browser. For example, it can animate certain transitions when you click, it can sum up the price of your 3 movie tickets without checking the server, and it can request more data from the server it came from. Importantly, it cannot request data from other servers, because that would open up a slew of security issues (I won’t get into them now.)
However… there are a few exceptions. You can load an image from a different server… but that’s considered okay because the browser will then directly render the image to the user, and the HTML page that loaded the image doesn’t get access to the image itself. For example, theoretically, I could write a web page that includes an image from your local machine (more or less), if I know exactly where it’s stored, but I won’t be able to load that image back to my server. It’s a bit like walking a tight rope, isn’t it? Sounds really close to evil, but you can’t quite figure out anything really wrong with it.
But it’s also important not to go overboard. I don’t agree with Joe’s final recommendation, that JSON should only be used for public data. He’s worried about the use of this kind of attack in combination with Cross-Site Request Forgery…. which is a bit of an odd description since JSON is meant specifically for cross-site requests.
That said, private-data JSON is still safe, if used with full awareness of how JSON is actually evaluated.