Thursday, 24 November 2011

There is No Security in NoSQL

An interesting paper “Security Issues in NoSQL Databases” in the proceedings of the 2011 International Joint Conference of IEEE TrustCom-11/IEEE ICESS-11/FCST-11 reviews two of the most popular NoSQL databases (Cassandra and MongoDb) and outlines their main security features and problems.

The conclusions are “Clearly the future generations of such DBMSs need considerable development and hardening in order to provide secure environment for sensitive data which is being sored by applications (such as social networks) using them.” An interesting article about the paper can be found here.

Let’s investigate this further!

What is a NoSQL Database?

A NoSQL Database is a database that is not relational by definition and does not support full SQL (Structured Query Language) functionality. A typical relational DBMS (Database Management System) performs poorly on data-intensive applications needed for high-traffic websites.

A NoSQL database focuses on performance and scalability, has a simple data-model, a primitive query language and no mechanisms for managing data consistency and integrity constraints.

Status and Recommendations

The paper itself concluded that the main problems to both Cassandra and MongoDB are “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”.

The following table describes the security posture and recommendations for Cassandra:

Category Status Recommendations
Data at rest Unencrypted. Protect with OS level mechanisms.
Authentication The available solution isn’t production ready. Implement a custom IAuthentication provider.
Authorization Done at the CF granularity level. The available solution isn’t production ready. Implement a custom IAuthority provider.
Auditing Not available out-of-the-box. Implement as part of the authentication and authorization solutions.
Intercluster network communication Encryption is available. Enable this using a private CA.
Client communication No encryption is available. Add packet-filter rules to prevent unknown hosts from connection. Re-implement the Thrift server-side to use the SSL transport in Thrift 0.6. Add timeouts for silent connections in the Thrift server side, and cap the number of acceptable client connection.
Injection Attacks Possible in CQL (Cassandra Query Language). If using the Java driver, prefer PreparedStatements to Statements. Always perform input validation in the application.

The paper states that “security was not a primary concern of MongoDB’s designers. As a result there are quite a few holes in its design”. The following table describes the security posture and recommendations for MongoDB:

Category Status Recommendations
Data at rest Unencrypted. Protect with OS level mechanisms.
Authentication for native connections Available only in unsharded configurations. Enable if possible.
Authorization for native connections READ/READ-WRITE/Admin levels, only in unsharded configurations. Enable if possible, requires enabled authentication.
Auditing Not available in MongoDB  
AAA (authentication, authorization, auditing) for RESTful connections Users and permissions are maintained externally. Available if configured on a reverse proxy.
Database communication Encryption is not available.  
Injection Attacks Possible, via JavaScript or string concatenation. Verify that the application does reasonable input validation.

Note: some of the security issues might have been fixed in later version than reviewed in the paper. The authors reviewed Cassandra 0.8.X but did not mention the version under review for MongoDB.


Well, since NoSQL databases where never designed for security, it will be very difficult if not impossible to fix all issues. I cannot imagine the use of a ‘proxy’ will ever be implemented: if high availability is your primary concern, you just don’t add another component.

NoSQL databases certainly have their uses, but unfortunately, they are already in used in situation (e.g. privacy related data) where security is certainly needed.

Not providing any security measures and even making it impossible to audit access does not seems to me the brightest idea ever, but I’m sure - in the not so distant future - it will make the life of hackers and pen-testers a lot easier. Let me also be the first to ROFL when I’ll hear the term APT (Advanced Persistent Threat) being used in connection with a break-in into a NoSQL database.   

“It was a programming technique that had been reverse-engineered from the sort of psychotic mental blocks that otherwise perfectly normal people had been observed invariably to develop when elected to high political office”. (Douglas Adams, Mostly Harmless)

Further References

[1] Lior Okman, Nurit Gal-Oz, Yaron Gonen, Ehud Gudes, Jenny Abramov in “Security Issues in NoSQL Databases” in Proceedings of the 10th IEEE International Conference on Trust, Security and Privacy in Computing and Communications (IEEE TrustCom-11), November 2011, Changsha, China

[2] Christof Strauch in “NoSQL Databases” (2011)

[3] Bryan Sullivan in “NoSQL, But Even Less Security: Attacking and Defending NoSQL”  (Presentation, RSA Conference, Europe 2011)


2011/11/24 - First version


  1. Wow! Such a sweeping statement about a segment of technology with only two data points! I suggest a little more research before making such a statement. Here are two contradicting cases: eXist-db Open Source Native XML Database and MarkLogic.

  2. Yes, I agree with Loren. As a person that has been using eXist and MarkLogic for several years it is clear that NoSQL systems DO have robust security infrastructure. The author just has a very narrow perspective.

  3. Correct about the lack of data points, but they did test the most popular (public domain) NoSQL databases. I have little faith that other public domain databases will do better. I will have a look at eXist-DB (at least they have information about the security configuration), but cannot form an opinion on MarkLogic, since it is commercial and I cannot do any testing. Please do not get me wrong, NoSQL databases are great, but if they are used to store privacy related data (or confidential data) one must take care. In some cases this can be difficult.

  4. I would be happy to talk with you about eXist-db security. We do take security seriously.

  5. Just wanted to point out that NoSQL comes in many many flavors.

    Exist-db is an XML based database, and I don't think it is quite comparable to Mongo or Cassandra. The point in both Mongo and Cassandra is that they are distributed, while exist-db seems to be a non-clustered installation. You can't run distributed queries over exist-db, while that is the entire point in Mongo and Cassandra. Naturally, security is easier to do if you aren't distributed.

  6. Today, three interrelated megatrends – Big Data, Big Users, and Cloud Computing – are driving the adoption of NoSQL technology.