Safe JSON (via) Subtle but important point about JSON APIs: you shouldn’t use a callback or variable assignment for JSON incorporating private user data, especially if it’s at a predictable URL.
You did put the caveat of "predictable URL", but the point could be clearer: for many applications, JSON callbacks on APIs for unpredictable URLs are no less secure than, say, session IDs.
This is a concern for large distributions, important or well-known products, and otherwise critical applications, but a brute force attempt to get data from JSON via a very large URL space? Meh, I've got falling asteroids to worry about. :)
As with any of these things, it's important to keep in mind however unlikely you think a successful exploit might be.
I can see it being used in more targeted attacks against users of an exploitable service. It's simply going to be a case of getting that user to hit your dodgy page with their session authenticated and you can get their private data.
It that sense it becomes as dangerous as leaving your service open to basic XSS exploits, even if the service in question is neither widely distributed, important or well-known.
Sign in with 
OpenID
I have to say, this post strikes me as alarmist.
You did put the caveat of "predictable URL", but the point could be clearer: for many applications, JSON callbacks on APIs for unpredictable URLs are no less secure than, say, session IDs.
This is a concern for large distributions, important or well-known products, and otherwise critical applications, but a brute force attempt to get data from JSON via a very large URL space? Meh, I've got falling asteroids to worry about. :)
Jeremy Dunck - 2nd March 2007 15:35 - #
As with any of these things, it's important to keep in mind however unlikely you think a successful exploit might be.
I can see it being used in more targeted attacks against users of an exploitable service. It's simply going to be a case of getting that user to hit your dodgy page with their session authenticated and you can get their private data.
It that sense it becomes as dangerous as leaving your service open to basic XSS exploits, even if the service in question is neither widely distributed, important or well-known.