CODEWITHSUNDEEP
mongodbmeteor
TDawg
TDawg

Reputation: 883

MeteorJS App Security

I was a bit curious for feedback on security of the following structure:

Meteor server side app (using Mongo of course) Meteor Mobile App, I understand this has a mini-Mongo

From the tutorials I read, the local mini-Mongo saves data needed for the mobile app, while calls to sync with the parent mongo on the server happens when there is a network connection.

Is it my responsibility on a code level to restrict what gets saved in client mini-Mongo? Examples:

This might have the answer: How do I create a meteor topic that is for server-only security sensitive information (client cannot subscribe)?

Upvotes: 0

Views: 79

Answers (1)

MasterAM
MasterAM

Reputation: 16478

MiniMongo basically stores data it gets from certain messages over DDP (Meteor's data protocol). Normally, the data is not cached locally and is re-created each time the page reloads, assuming we're talking about a hybrid mobile app that's rendered in a WebView.

You can take a look at the messages passed using Meteor DevTools for Chrome.

Those messages (added/changed/removed) are normally sent via the pub/sub system. It is indeed you responsibility to decide what gets sent. You have complete control over modeling roles and permissions in your system, and over who gets what in your publication, since a publication is initiated by a function call on the server.

A common pattern for this is:

Meteor.publish('someProtectedPblication', function(/*...*/) {
  if (this.userId && someCondition(this.userId) { // check for permission
    return SomeCollection.find(someData, someFields); // return a cursor that gets synced with the user
  }
  return this.ready(); // the user is not authorized to view the data
});

When an admin creates a user, I assume this is done via a Meteor method call, i.e, an RPC. There is no reason for that user's data (not to mention their hashed password) to be available to the admin on the client side, or stored in his cached database collection, unless you explicitly publish it to him (which I don't see a reason to do, ever).

I don't find much value in using client-side MiniMongo mutations (insert/update/delete) on the client side, except for optimistic UI rendering, as I view securing this using allow/deny rules less secure and more error prone, and I use Meteor methods for any mutation.

Upvotes: 3

Related Questions