What security mechanisms does Meteor have?

Question

We all know that Meteor offers the miniMongo driver which seamlessly allows the client to access the persistent layer (MongoDB).

If any client can access the persistent API how does one secure his application?

What are the security mechanisms that Meteor provides and in what context should they be used?

I love that this is being addressed already, but they really should have mentioned this in the video. I think pretty much any web developer watching it will have this question on their mind as of 10 seconds in until the end of it, and just feel annoyed that for such an awesome product they APPEAR to be ignoring the obvious security problem entirely. — Naatan, Apr 12 '12 at 14:19
Meteor 0.5.0 added user authentication http://meteor.com/blog/2012/10/17/meteor-050-authentication-user-accounts-new-screencast — hipertracker, Oct 24 '12 at 08:46
You could reword this a bit to get it re-opened. Perhaps "What security measures should I take?" or "What security options are available?" — joeytwiddle, Nov 28 '13 at 08:04
Opinion based? Wat? I thot this was a reopen audit since it is obviously not opinion based. — bjb568, Apr 22 '14 at 03:19
I kind of agree, the opinion based ruling is out of context - answers are based on true facts. — Olivier Refalo, Apr 22 '14 at 13:53

score 64 · Accepted Answer · edited Dec 27 '12 at 07:49

64

When you create a app using meteor command, by default the app includes the following packages:

AUTOPUBLISH
INSECURE

Together, these mimic the effect of each client having full read/write access to the server's database. These are useful prototyping tools (development purposes only), but typically not appropriate for production applications. When you're ready for production release, just remove these packages.

To add more, Meteor supports Facebook / Twitter / and Much More packages to handle authentication, and the coolest is the Accounts-UI package

edited Dec 27 '12 at 07:49

avital

1,542
11
15

answered Oct 19 '12 at 03:30

Murali Ramakrishnan

856
7
7

2

Correct as of meteor 0.5 – Olivier Refalo Oct 19 '12 at 11:52
Just pointing out that accounts-ui is actually not powered by twitter bootstrap, though it can be used in combination with it. – avital Dec 27 '12 at 07:43
5

Insecure by default. Yikes. – Judah Gabriel Himango Mar 19 '13 at 18:26
16

@JudahHimango **insecure for testing purposes only**, and removing those two packages when you're ready for production is as easy as `meteor remove autopublish insecure`. – BenjaminRH Apr 08 '13 at 10:05
1

What about meteor methods? The client can access those from the console even with insecure uninstalled, because they are ran on the server. How can one make them secure? – Matanya Oct 26 '13 at 22:59
2

@Matanya but upon use and execution of those from console, it will throw an `access denied` error. Check it out. – ajduke Apr 04 '14 at 07:06

score 35 · Answer 2 · answered Apr 11 '12 at 04:39

35

In the collections doc says:

Currently the client is given full write access to the collection. They can execute arbitrary Mongo update commands. Once we build authentication, you will be able to limit the client's direct access to insert, update, and remove. We are also considering validators and other ORM-like functionality.

answered Apr 11 '12 at 04:39

pomber

23,132
10
81
94

1

Also se this thread on Quora with an answer from one of the Meteor developers: http://www.quora.com/Meteor-web-framework/Whats-cool-about-Meteor/answer/Rory-I-Sinclair/comment/878076 – dentarg Jun 17 '12 at 18:22
1

@jonathanKingston the link is broken, could you update it please? – Carlos Morales Jul 25 '13 at 14:00
@CarlosBarcelona The domain expired and the article was prior to the security updates in Meteor. I think it is fair to say it was out of date; so I have removed the comment to save people time. Thanks – jonathanKingston Aug 29 '13 at 21:48

score 5 · Answer 3 · answered Sep 21 '12 at 06:18

If you are talking about restricting the client not to use any of your unauthorized insert/update/delete API, thats possible.

See their, todo app at https://github.com/meteor/meteor/tree/171816005fa2e263ba54d08d596e5b94dea47b0d/examples/todos

Also, they have now added a built in AUTH module, that lets you login and register. So its safe. As far as you are taking care of XSS , Valiations, client headers etc.

but you can anyday convert meteor app into fully working nodejs application by deploying to node. So if you know how to secure a nodejs application you should be able to secure meteor.

This is completely true as of Sept 2012 – Olivier Refalo Sep 21 '12 at 15:14 — Olivier Refalo, Sep 21 '12 at 15:14

DrM · Answer 4 · 2013-07-02T17:56:42.107

2

As of 0.6.4, during development mode, is_client and is_server blocks still both go to the client system. I can't say if these are segregated when you turn off development mode.

However, if they are not, a hacker might be able to gain insight from the system by review the blocks of if(Meteor.is_server ) code. That particularly concerns me, especially because I noted that I still at this point can't segregate Collections into separate files on client and server.

Update

Well, the point is don't put security related code in an is_server block in a non-server directory (i.e. - make sure it is in something under the /server .

I wanted to see if I was just nuts about not being able to segregate client and server Collections in the client and server directories. In fact there is no problem with this.

Here is my test. It's a simple example of the publish/subscribe model that seems to work fine. http://goo.gl/E1c56

edited Jul 02 '13 at 17:56

answered Jul 02 '13 at 14:58

DrM

1,092
1
8
11

1

The solution would be to save your code in the server/ folder - this way it doesn't get pushed to the client. – Olivier Refalo Jul 02 '13 at 15:52
DrM, please see http://docs.meteor.com/#structuringyourapp — sensitive code does not need to be delivered to the client – emgee Jul 02 '13 at 16:16
Try something simple; create a collection in a server file, then create that same collection in the client file and tell me what happens. Next, create a root file with the declaration of the collection, then simply reference that in a server and client directory file and tell me what happens. If you can't create the collection, like I couldn't, how can you reference these independently? In the end, you need the reference to the collection to exist in the same client available file and use is_server and is_client. I hope I am wrong, but I haven't found out how or why yet. – DrM Jul 02 '13 at 16:39
Hmm, strange, testing seems to be fine, will update answer – DrM Jul 02 '13 at 17:40
The link is a repo to simple code, but seems to work fine, not sure what the weird errors were in the past or how I might recreate them. – DrM Jul 02 '13 at 18:02

What security mechanisms does Meteor have?

4 Answers4

Update

Linked