How to prevent invoking 'Meteor.call' from JavaScript Console?

Question

I just noticed that Meteor.call, the concept that prevent user from invoke collection's insert, update, remove method, still able to be invoked from JavaScript console.

For client's example:

// client
...

Meteor.call('insertProduct', productInfo);

...

Here's the server part:

// server
Meteor.methods({
    insertProduct: function( productInfo ){
       Product.insert(...);
    }
})

OK, I know people can't invoke Product.insert() directly from their JavaScript console.

But if they try a little bit more, they'd find out there's Meteor.call() in client's JavaScript from Developer tool's resource tab.

So now they can try to invoke Meteor.call from their console, then try to guessing what should be productInfo's properties.

So I wonder how can we prevent this final activity? Does Meteor.call done the job well enough? or I'm missing something important?

Answer 1

Meteor.call is a global function, just like window.alert(). Unfortunately, there is nothing you can do from preventing a user calling Meteor.call. However, you can validate the schema of data and the actual data of what a user is sending. I'd recommend https://github.com/aldeed/meteor-simple-schema (aldeed:simple-schema as the meteor package name) to ensure you don't get garbage data in your project.

Answer 2

As others pointed out, "Meteor.call" can surely be used from the console. The subtle issue here is that there could be a legal user of a meteor app who can in turn do bad things on the server. So even if one checks on the server if the user is legal, that by itself does not guarantee that the data is protected.

This is not an issue only with Meteor. I think all such apps would need to potentially protect against corruption of their data, even through legal users

One way to protect such corruption is by using IIFE (Immediately Invoked Function Expression)

Wrap your module in a IIFE. Inside the closure keep a private variable which stores a unique one time use key (k1). That key needs to be placed there using another route -- maybe by ensuring that a collection observer gets fired in the client at startup. One can use other strategies here too. The idea is to squirrel in the value of k1 from the server and deposit it in a private variable

Then each time you invoke a Meteor.call from inside you code, pass k1 along as one of the parameter. The server in turn checks if k1 was indeed legal for that browser connection

As k1 was stored inside a private variable in the closure that was invoked by the IIFE, it would be quite difficult for someone at the browser console to determine the value of k1. Hence, even though "Meteor.call" can indeed be called from the browser console, it would not cause any harm. This approach should be quite a good deterrent for data corruption