Rate limiting in Meteor core

By Anubhav Jain

In this post, we’ll talk about rate limiting, a common requirement of most web applications. Rate limiting can provide a first line of defense against users trying to spam content onto your website or attempting to use up server resources.

Survey of rate limiting in current web frameworks

Today, most popular web frameworks don’t provide security against denial-of-service (DoS) or dictionary password attacks out of the box. A quick Google search of rate limiting in web applications results in a lot of different rate limiting options; for example, there’s a solution for Flask that involves using Redis and a community package for Rails. However, none of these solutions are included in the frameworks by default. Rate limiting can also be the job of a web server or proxy, and many solutions exist at that level, but the state of rate limiting for websockets is a lot less mature.

Implementing Rate Limiting in Meteor

With the help of the Meteor community, we have identified the importance of rate limiting and thus are including a default rate limiting solution in Meteor 1.2. Meteor uses a websocket protocol called DDP to fetch structured data from the server and receive live updates when the data changes; this is a new kind of technology that requires new tools.

Out of the box, a lot of web frameworks are vulnerable to a simple password-checking script. Our solution to this is to limit how fast passwords can be tried by default in the accounts-base package. This limit will protect Meteor apps from attacks that involve resetting passwords, creating many new users, or trying many username/password combinations.

In addition to built-in support for user accounts, we are including a more general rate limiter for DDP so that developers can limit method and subscription calls. The rate limiter intercepts messages at the connection level, allowing it to determine whether we’ve hit limits and return errors without causing any extra server resource usage.

How to easily add rate limiting to your app!

Here’s a code sample adding a rule to the DDPRateLimiter in Meteor 1.2:

// Define a rule that matches add comment attempts by non-admin usersvar addCommentRule = { userId: function (userId) { return Meteor.users.findOne(userId).type !== 'Admin'; }, type: 'method', method: 'addComment'}// Add the rule, allowing up to 5 messages every 1000 milliseconds.
DDPRateLimiter.addRule(addCommentRule, 5, 1000);

Let’s look at what this is actually doing:

• A rule is defined as a set of key-value pairs where the keys are one or more of userId, clientAddress, type, name, and connectionId. The values can either be null, primitives or functions. When you want to rate limit some users but not others, a rule can match invocations using a function in a way that is determined at run time based on the database or other data. In our example, we check the database to avoid rate limiting admin users.
• When we add the rule to DDPRateLimiter, we also specify the number of messages that we allow and the time interval on which the rate limit is reset.

Coming soon as part of Meteor 1.2

As a part of the new release, current applications using the accounts-base package will have the login rate limiting added in by default but we've provided a simple way to remove the default rule as well. These are part of continuing improvements for the Meteor DDP client & server system and will be available as a part of Meteor 1.2, which you can read more about in Matt's recent blog post.