Finding Methods

Below you'll find a sample chapter from Secure Meteor; a guide to help you learn the ins and outs of securing your Meteor application from a Meteor security professional. If you like what you read and you're interested in securing your Meteor application, be sure to read the entire book!

Let’s pretend for a moment that we’re not the good natured Meteor developers that we are, and instead let’s pretend that we’re malicious users intent on exploiting your application for fun and profit.

The first thing we do when we come across a Meteor application is open our browser’s console and inspect the Meteor.connection object. Meteor’s connection object holds a wealth of information about the browser’s active connection to the Meteor server, including all of the ways of interfacing with that server. I highly recommend you take a minute, open up your own Meteor application, and explore the Meteor.connection object within your browser.

You’ll be amazed at what you find!

One of the most common and arguably most powerful ways of interacting with a Meteor server is through its Meteor methods. The connection object contains the full method name and source code for all publicly-visible Meteor methods. Each key in the Meteor.connection._methodHandlers object is the name of a Meteor method, with the corresponding value representing the actual method itself (including its source code).

Assuming the application defines an updateCart method, we could easily discover that method and see it’s source from within our browser:

If we were looking for missing or incomplete argument checks, we’d have to look no further.


The connection object isn’t the only place we have to look for methods. Maybe there are Meteor methods defined in the application that aren’t defined in a shared location. Their definitions exist only on the server.

While a method’s definition might only exist on the server, it’s still most likely callable from the client (unless special work has been done to prevent this). In this case, all we need to do to discover the existence of these hidden Meteor methods is to sleuth through the client-side Javascript bundle looking for references to Meteor.call.

The client-side bundle is named uniquely for every build of your application, but it’s always linked directly within the client-side source of the application, immediately following the __meteor_runtime_config__ definition.

Once the client-side bundle is opened, a malicious user can find all Meteor method calls made by the client by simply searching for them. Meteor’s build process sometimes minifies references to the Meteor global object, so rather than searching for Meteor.call(", we’ll search for .call(". When we find calls to Meteor methods scattered throughout the client’s source, we can see the name of the method, and number of arguments typically passed to the method. Using this information, we can apply some deductive reasoning to infer what exactly those arguments typically are.


Just like we can find Meteor methods by sleuthing through the client’s Javascript bundle, we can also discover Meteor methods by listening to the WebSocket connection between the client and the server.

By opening our browser’s network tab and finding the /websocket request, we can individually inspect every “frame” that’s sent between the client and the server. Every time a Meteor method is called by the client, a WebSocket "method" frame is sent to the server. This frame contains the method’s name and arguments:

Once we’re aware of the existence of the method, we could recreate the call manually in our console:

From there we can start playing with the expected arguments, looking for vulnerabilities:


Sometimes Meteor methods are defined entirely on the server and are called exclusively by other methods visible only on the server. In cases like these, no amount of digging through our connection object, searching through the client-side bundle, or monitoring WebSocket frames will lead to the discovery of these (often very interesting) Meteor methods.

As a last resort, an attacker might resort brute force Meteor method discovery. The Meteor framework will happily tell us if a method we’re attempting to call exists or not. For example, if we attempt to call a non-existent Meteor method, foo, the server will respond back with a "Method 'foo' not found" exception.

This means that we can construct a massive list of potential Meteor method names, and attempt to call each from our browser’s console. If we receive anything other than a "Method 'foo' not found" response from the server, we know that the Meteor method in question exists on the server:

In this case, our resulting object would show that updateCart exists as a method, but foo and bar do not.

While this simple example demonstrates the idea of using the Meteor framework to tell us whether a method exists, this idea can be elaborately extrapolated upon using many kinds of techniques for generating method names.