NoSQL Injection in Meteor.js Application

By on August 6, 2016

All thing about NoSQL Injection in Meteor Application

This is one of two topics of our 2nd Meteor Meetup on July 9th, 2016. The author is Son Le, a young talent member of Designveloper.

Those who were not able to attend our 2nd Meteor Ho Chi Minh meetup at July 9th could find all about NoSQL Injection in Meteor.js Application – one of the main topics of the meetup – in this blog.

Before digging into every facet of this post, you are required to have a fairly good background of Meteor and MongoDB, which is the most widely used NOSQL database. If you are a Meteor-novice, no worries! You can discover more about this full-stack JavaScript platform for developing single-page, real time web and mobile apps at

Now, are you ready to get what you missed at our Meetup?


SQL Injection is defined as a code injection technique, used to attack data-driven applications, in which nefarious SQL statement are inserted into an entry field for execution. (Source: Wikipedia)

In other words, SQL injection is a technique where malicious users inject SQL commands into an SQL statement to change it and compromises the security of a web application with SQL database.

There are 4 common forms of technical implementations of SQL injection:

  • Incorrectly Filtered Escape Characters with this line of code:
statement = "SELECT*FROMusersWHERE name = '" + userName + "';"
  • Incorrectly Type Handling:
statement := "SELECT*FROMuserinfoWHEREid=" + a_variable + ";"
  • Blind SQL Injection:
  • Second order SQL injectionI am going to give you an example of Incorrectly Filtered Character. Here I want to get a user data with username Peter and password “$PWQ”, the query looks something like this:
    // query
    SELECT * FROMusers 
    WHERE username='peter’
    AND (password=('$PWD'))

    If I use a “weird” input, for example:

    // input
    ' OR '1'='1’

    The result query is:

    // result
    SELECT * FROM users 
    WHERE username='peter' AND (password='' OR '1'='1')

    As you can see, the condition (password=” OR ‘1’=’1′) is always true. That’s why the result query is always successful. By this way, attackers can get any arbitrary user data, given the username.


    Now, although NoSQL is still a popular attacking technique, it’s no longer as widespread as it used to be. Many modern apps use NoSQL databases such as MongoDB for its simplicity and speed. Unlike SQL in which queries use STRINGs as the control mechanism, NoSQL queries use OBJECTs instead. With NoSQL Injection, instead of injecting STRINGS as parameters, attackers use SUB-OBJECTs as parameters to inject database queries.

    The SQL statement that we used above to query the user login details will be written like this in MongoDB:

    db.users.find({username: username, password: password});

    As mentioned before, attackers can use subobjects as parameters to inject to NoSQL database queries, for example:

    	username: “peter”,
    	password: { $gt: “” }

    In the above query, the $gt operators stands for “greater than”. The password is not validated to ensure that it is string. Therefore, when the JSON document is deserialized, that field may contain anything but string that can be used to manipulate the structure of the query. You can get that what the query does is comparing the password of “peter” with an empty string, so this condition is always true.

    In MongoDB, there’re many similar operators, like $gt that attackers can take advantage of, such as: $gte (greater than or equal to), $lt (less than), $lte (less than or equal to), $ne (not equal to), $nin (matches none of the values specified in an array), etc.


    Here comes the Meteor part. Typically the default data layer of Meteor applications in MongoDB, which puts Meteor apps in the risk of being exploited using the NoSQL Injection technique. Let’s get into one demo application for testing NoSQL Injection: meteor-shop. you can clone the app from This web application is written in Meteor. Please follow the instruction in file for how to setup and run the app in your local machine.

    All thing about NoSQL Injection in Meteor Application

    In the scope of Meteor, attackers usually take advantage of publication functions and methods. For example, you can see that in the publication.js file we have this publication function:

    // Get the products, filtered by their vendor
    Meteor.publish("products-by-vendor", function(slug){
      return Products.find({"vendor.slug" : slug})

    We (as developer) are expecting the slug information to be a string, but haven’t check for that condition. So whatever input can be injected into this function, which makes it vulnerable to NoSQL Injection. For example. an attackers can do this (in browser console) to get all the documents in the Products collections:

    Meteor.subscribe(“products-by-vendor”, { $ne: null })
    Products.find().fetch() // Now all products in the database are shown !

    You can take a look at the server/publication.js file and meetup.js file. Those files contain some examples to help you play around with NoSQL in the demo app.


    Through those example above, hopefully you can see the potential of NoSQL Injection being a threat to apps using NoSQL databases. So how do we prevent this problem?

    Fortunately, it’s pretty easy in the scope of Meteor to prevent the app from being attacked by NoSQL Injection. In general, there’s only one thing to keep in mind: Never completely trust user inputs. We must always get them validated before passing them as parameters to publication functions and methods. Meteor has a handy package which do the exact same thing called check. This package will allow us developers to check if the input parameter match the defined type. So, one can’t inject a JavaScript object as parameter to a function which requires a string, for example.

    The check package is quite useful but what if your project has so many publication functions/methods that you don’t know if their parameters have been checked or not? Then here comes audit-argument-check and check-checker, those package will throw warnings if there’re methods that haven’t been checked by the check package.

    Wrapping Up!

    Walking through this blog, we’ve discovered more about NoSQL Injection:

  • How it works and some examples
  • How to prevent it in general and in the scope of Meteor
  • So, did you find some great information of your own in this blog? What am I missing? Let me know in the comments and I’ll add it in!If you enjoyed this post, I’d be very grateful if you’d help it spread by emailing it to a friend, or sharing it on Twitter or Facebook. Thank you!

You may also like:

Leave Comment

About Author


Hi, my name is Van. I’m a stubborn introvert, an iced milk tea drinker, a barefoot kitchen dancer, a singer of shower time and an enthusiastic copywriter dying to write about anything around my world.



  • Today Visitor: 113
  • Month Visit: 59,371
  • Total Posts: 121


Facebook By Weblizar Powered By Weblizar