Co-authored by Emanuel Bronshtein

Are you using one of the trending NoSQL databases such as MongoDB or CouchDB? Or maybe you are thinking of using one of those but are troubled by how secure they are? We will discuss the security of the application programming interfaces (APIs) and software development kits (SDKs) of NoSQL databases, while also diving into the application code consuming these databases and providing some examples and advice on the risks and mitigations.

NoSQL Databases Still Have Risks

NoSQL, which stands for Not Only SQL, is a common term for nonrelational databases. Among popular NoSQL databases you will find the aforementioned MongoDB and CouchDB, along with Redis, Cassandra and more. NoSQL databases have become increasingly popular thanks to their benefits in particular use cases, especially in big data and real-time Web usages where performance, scalability and flexibility are key.

Database security has been and will continue to be one of the more critical aspects of application security. Access to the database grants an attacker a dangerous amount of control over the most critical information. Although the number of SQL injection vulnerabilities has been declining since 2008 due to use of secure frameworks and improved awareness, it has remained a high-impact risk.

With the emergence of new databases and query techniques, the old attack methods become obsolete and new ones emerge. For example, most NoSQL databases do not use SQL and instead use the JavaScript Object Notation (JSON) query language and an HTTP API. This makes old techniques like SQL injection obsolete. However, NoSQL definitely does not imply zero risk. In fact, NoSQL databases are vulnerable to injection attacks, cross-site request forgery (CSRF) and other vulnerabilities.

In a paper we presented at the Web 2.0 Security and Privacy conference titled “No SQL, No Injection? Examining NoSQL Security,” we demonstrated a number of techniques for injections in different runtimes using MongoDB. Additionally, the paper discusses Web APIs and their risks, such as CSRF, and some deployment recommendations. We recommend reading the paper, which includes actual code samples of possible exploits.

Knowing the risks is key for protecting against them. Having automated security testing is also significant for achieving consistent results. Web application scanners, for instance, can use rules for finding vulnerabilities in NoSQL databases to help you protect against the new exploitation techniques.

Examples of NoSQL Exploits

For those of you who prefer to get more technical, here are a few examples of exploits. More are fleshed out in the full paper.

Consider the following situation: A PHP application has a login mechanism where the username and password are sent from the user’s browser via HTTP POST. This vulnerability is applicable to HTTP GET, as well. A typical POST payload would look like:


The backend PHP code to process it and query MongoDB for the user would look like:






But PHP has a built-in mechanism for associative arrays that allows an attacker to send the following malicious payload:


PHP translates this input into:


“username” => array(“$ne” => 1),

“password” => array(“$ne” => 1)


MongoDB keywords start with a dollar sign and, specifically in this example, $ne is the keyword for the not equals operator, which means select all documents where username is not equal to 1 and password is not equal to 1.

To mitigate this issue, cast the parameters received from the request to the proper type, in this case string:






Another language-agnostic example that is one of the common reasons for SQL injections stems from building the query from string literals, which include user input without proper encoding. The JSON query structure makes this harder to achieve in modern data stores such as MongoDB. Nevertheless, it is still possible. Let’s examine a login form that sends its username and password parameters via an HTTP POST to the back end, which constructs the query by concatenating strings. For example, the developer would do something like:

string query =

“{ username: ‘” + post_username + “‘, password: ‘” + post_password + “‘ }”

With malicious input, this query can be turned to ignore the password, allowing the attacker to log into a user account without the password. An example for malicious input:

Username: tolkien’, $or: [ {}, { ‘a’:’a

Password:‘ } ], $comment:’successful MongoDB injection’

Without encoding, this input will be constructed into the following query:

username: ‘tolkien’,

$or: [ {}, { ‘a’: ‘a’, password: ” } ],

$comment: ‘successful MongoDB injection’

That is, the password becomes a redundant part of the query because an empty query {} is always true and the comment in the end does not affect it. Today, every language has good native libraries for JSON encoding, so there is no reason to construct JSON queries from strings. For more examples and information on other risks such as CSRF, we recommend you read the complete paper.

More from Application Security

X-Force Identifies Vulnerability in IoT Platform

4 min read - The last decade has seen an explosion of IoT devices across a multitude of industries. With that rise has come the need for centralized systems to perform data collection and device management, commonly called IoT Platforms. One such platform, ThingsBoard, was the recent subject of research by IBM Security X-Force. While there has been a lot of discussion around the security of IoT devices themselves, there is far less conversation around the security of the platforms these devices connect with.…

4 min read

Patch Tuesday -> Exploit Wednesday: Pwning Windows Ancillary Function Driver for WinSock (afd.sys) in 24 Hours

12 min read - ‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. As security improves and exploit mitigations become more sophisticated, the amount of research and development required to craft a weaponized exploit has increased. This is especially relevant for memory corruption vulnerabilities.Figure 1 — Exploitation timelineHowever, with the addition of new features (and memory-unsafe C code) in the Windows 11 kernel, ripe new attack surfaces can…

12 min read

Backdoor Deployment and Ransomware: Top Threats Identified in X-Force Threat Intelligence Index 2023

4 min read - Deployment of backdoors was the number one action on objective taken by threat actors last year, according to the 2023 IBM Security X-Force Threat Intelligence Index — a comprehensive analysis of our research data collected throughout the year. Backdoor access is now among the hottest commodities on the dark web and can sell for thousands of dollars, compared to credit card data — which can go for as low as $10. On the dark web — a veritable eBay for…

4 min read

Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers

17 min read - Overview In this post, IBM Security X-Force Red offensive hackers analyze how attackers, with elevated privileges, can use their access to stage Windows Kernel post-exploitation capabilities. Over the last few years, public accounts have increasingly shown that less sophisticated attackers are using this technique to achieve their objectives. It is therefore important that we put a spotlight on this capability and learn more about its potential impact. Specifically, in this post, we will evaluate how Kernel post-exploitation can be used…

17 min read