In the past I’ve written about how a potentially malicious user can view all of the isometrically defined methods in your Meteor application. By inspecting the Meteor.connection._methodHandlers object on the client, they can see all client-side executable instances of your methods, which in most cases are identical to your server-side executable methods. This lets an attacker identify weaknesses in your application security that may lead to an attack.

Meteor.connection._methodHandlers only poses a potential problem for methods defined in a shared location. Methods defined in a server.js file, or within a server/ folder will never be shipped to the client, and won’t appear in the _methodHandlers object.

However, defining methods in server-only locations doesn’t mean your methods are free from prying eyes! Depending on how your application is structured, it may still be possible for an attacker to find and exploit these methods.

Source Snooping

Even if a method is defined in a server-only location, it’s still accessible from the client. For example, if you have a method defined in a server.js file:

Meteor.methods({
  hiddenMethod: function(argument) {
    // Do secret things...
  }
});

That method can still be called from the client:

Meteor.call("hiddenMethod", argument);

This means that one way of discovering hidden methods within a Meteor application is to simple search the bundled application source for Meteor method calls.

When the Meteor application is minified, the Meteor object is often transformed into some other variable name, so rather than searching for /Meteor\.call("/, it’s better to search for /\.call("/:

For example, in the above screenshot we can see a call to a Meteor method called "increasePostViews". This method is taking two arguments. I wonder if both of those arguments are being checked?

Watching the Wire

An alternative to searching through the source for method calls is to simple watch all of the DDP requests that are sent over the websocket connection. Any calls to Meteor methods will be clearly marked, along with a list of arguments being sent to this method.

As you go about using the application, you can build up a list of Meteor methods, some of which may not have a corresponding handler in the Meteor.connection._methodHandlers object.

In the above screenshot, we can see a call being made to the "upvotePost" method with a single arguments.

Well Kept Secrets

These techniques will only reveal hidden methods that are being called by client-side or shared code. It’s still possible that the Meteor application may have other, completely hidden methods. These methods may be defined on the server, and only called by other server-only code.

In that case, the only way for a curious client to discover those truly hidden methods is make a call to every possible Meteor method to determine if it exists on the server. Thankfully, this kind of brute forcing is totally unfeasible, and would most likely never be worth an attacker’s time.

At the end of the day, it shouldn’t matter whether attackers know methods exist. Even your most secret of methods should be made secure. Always assume that all of your methods will be called by all users, because they can be!