Handling JSON data securely, Five JavaScript Tips in Five Days

JSON (JavaScript Object Notation) is a lightweight data format commonly used in Ajax requests. Unfortunately, JSON has some inherent security concerns. In this post, I'll discuss the problem with JSON and the fix that makes it safe to use in your Rich Internet Applications.

When a Web application makes a client-side request for data from a server (that is to say, uses Ajax), you have to select the appropriate format for the returned data.

For simple responses, plain text makes a lot of sense: It requires little effort to send from the server or handle in the client and has the added benefit of being rather secure.

Plain text is implausible, though, for situations in which more data is being transferred, particularly organized and nested data, such as the records being returned from a database query. For such situations, the logical and historical solution is XML (eXtensible Markup Language).

XML is still a standard and useful format, but it's considerably bulky, both in terms of the amount of data needing to be transferred (with all those opening and closing tags) and in terms of the amount of code required to parse out the individual values.

A much lighter-weight alternative is JSON. Data transferred in the JSON format will download faster and is much easier to parse in the handling client-side JavaScript, but the downside to JSON is big: an increased security risk. The security concerns in using JSON come from the use of the eval() function, a big security concern in any language:

var data = eval('(' + JSONresponse + ')');

The eval() function will execute that response data as JavaScript code, making the application open to many kinds of security hacks (such as Cross Site Request Forgeries, to name one). This does not mean that JSON should not be used. If you take the proper precautions, JSON can still be a secure data format in your Ajax sites. There are two approaches you can take (together or separately): ensure that the data is safe or avoid using eval().

To get away from using eval() directly, one relatively simple improvement is to use a JavaScript parsing library. There are a couple listed at www.JSON.org, including the JSON2 parser and the JSON sans eval() parser (sans is French for "without"). Considering the added security benefit of not using eval() directly, there's little reason not to use a parsing library.

The second security approach is to try to guarantee the integrity of the JSON data.

Performing XMLHttpRequests has some built-in integrity, as those requests can only be made on the same domain. But there are ways around that limitation, and even without any circumvention, the client side of your Web application is still reliant upon the security of your server-side code. But what if you're not using XMLHttpRequests? The solution there is to simulate the same-domain restriction by having the client and server pass a token back and forth. The validation of that token would confirm that the communication is appropriate (and not, for example, being forged by a malicious site).

Just taking these two steps (using a JSON parser and using a representative token) will provide your sites with a reasonable amount of security when you want to use JSON data. For added security, you can use HTTPS connections, of course, use cookie-based authentication (which is readable in both the client and server), or use something like Direct Web Remoting, a Java library that runs on the server but can interact with JavaScript in the browser.

For more on related topics, please check out my books. And be sure to check back here each day this week for more JavaScript tips.