I was interested to read a post from Trustwave Spiderlabs, dated March 13, called MongoDB –Security weaknesses in a typical NoSQL database. The discovered problems were fundamental and concerned various authentication issues, vulnerability to SQL Injection, and others.

Skip back two years to the report reviewing MongoDB and Cassandra, Security Issues in NoSQL Databases, in the proceedings of the 2011 International Joint Conference of IEEE TrustCom-11/IEEE ICESS-11/FCST-11, and we find the following conclusion:

"The lack of encryption support for the data files, weak authentication both between the client and the servers and between server members, very simple authorization without support for RBAC or fine-grained authorization, and vulnerability to SQL Injection and Denial of Service attacks"

It is perhaps surprising to find, two years on, MongoDB still has these same vulnerabilities.

When the NoSQL movement appeared, apparently out of nowhere, its evangelists claimed that the relational database was as doomed: the future lay with NoSQL. We wondered why it was that relational systems struggled with huge multi-terabyte databases, whereas NoSQL could scale out infinitely. The truth is that NoSQL disposes of many of those comforts we take for granted in commercial IT. As well as the obvious compromise in 'transactionality', the ability to maintain ACID transactions when changing data, it seems that there is a second one, security. If security were a high priority to MongoDB, the elementary loopholes such as requiring no credentials on initial install, having read/write access without granularity and both transmitting and storing data unencrypted would now be fixed.

Transactionality, security and data integrity comes at a considerable cost. The technology is dauntingly complex. Security 'defence in depth' doesn't come cheap. If you don't need these features, then of course you possibly don't need a relational database. NoSQL proponents will suggest that we achieve security by securing everything around it, doing data integrity in the application and relying on eventual consistency. Sure, or you might as well just write your own database too, an idea that has struck down an alarmingly large number of developers.

Before adopting NoSQL for a commercial application that needs consistency and durability, you need to be sure that it can pass your security audit, and comprehensive stress testing. In other words, you need to be satisfied that the product actually provides all those niceties that the user of relational database systems take for granted. If you find you have to put development effort into adding those features, the cost of a relational system will begin to look like money well spent.