This morning I was discussing the JSON data format with the co-authors of our upcoming book Enterprise Web Development (you can read its draft at http://enterprisewebbook.com/). We were discussing pros and cons of using the JSON format in the Web and the role of the JavaScript eval() function in the history of the Web development. As a result of this discussion, some of the new content can be added to the book section on JSON, for example:

“Usually, JSON-related articles and blogs are quick to remind you about the evil nature of the JavaScript function eval() that can take any JavaScript and execute it. The JSON.parse() is pictured as a protection against the malicious JavaScript that can be injected into your appplication’s code and then executed by eval() by your Web browser. The main argument is that JSON.parse() will not be processing the incoming code unless it contains valid JSON data.”

 But our discussion had a part that won’t make it into the book (O’Reilly’s editors are pretty strict), but can be shared with you in this blog. Protecting your application’s fragile body from being infected by means of eval() can and should be done outside of your application code by using HTTPS protocol and eliminating the cross-origin scripting by routing all requests to third-party data sources via proxying such requests through your own hosts. If the previous statement seems to be to complicated for understanding, I’ll give you another explanation that any adult software developer will understand.

If a man puts on a condom before having sex with a woman domestic partner, it’s like calling JSON.parse() – both are guaranteed that no malicious stuff will be injected. But if a man approaches a woman domestic partner without a condom, but holding a piece of paper signed by a venereologist certifying that this man is healthy – it’s like allowing using eval(), but providing protection at the security layer of your Web application.

Got it?