JSON, an acronym for JavaScript Object Notation, has often been compared to XML as a leaner form for serializing objects into data, where the contents may be understood by humans without de-serialization. It is very popular for passing objects over HTTP, as found in REST services, and is used elsewhere as a data transfer technique.
However, JSON, unlike XML, also allows for the encapsulation of JavaScript, allowing browsers, and JavaScript enabled code, to be able to execute the JavaScript contained therein. JSON is similar to using XML and VB Script combined. The difference is that VB Script is not a native language of any browser, while JavaScript is.
The point is that JSON is not simply a DTO (Data Transfer Object) that may be sent over the HTTP protocol without modification. It may be used as a DTO, because it contains data. But it allows for a much richer concept. It has the ability to encapsulate methods and logic. Depending on the destination, it has the ability to do harm.
As we continue to use HTTP as a transport for more and more sophisticated applications, we are also enabling consumer technologies to do more. You see this in applications on smaller devices such as smart phones or tablets. We pass JSON to our applications and consume the contents on the client side. When the JSON carries application code, the options are much more powerful, and susceptible to hacking threats. Not everything client has the ability to execute embedded JavaScript. When it does, there is the ability to do more.
Now we are bringing JSON into SQL Server as being seen in the community previews. What is the risk in this new capability? Probably none if SQL Server is simply a host for data. Even if it stores JavaScript embedded in JSON, unless SQL Server has the ability to execute the stored JavaScript, again the risk is probably Zero. But, if we can’t execute the JavaScript, does it not reduce the value of including JSON as a native type in SQL Server? Do we care? What do you think?
Cheers,
Ben