What security mechanisms does Meteor have? [closed]

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?

Metrify

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. – Theurer

Meteor 0.5.0 added user authentication meteor.com/blog/2012/10/17/… – Fondea

You could reword this a bit to get it re-opened. Perhaps "What security measures should I take?" or "What security options are available?" – Mere

Opinion based? Wat? I thot this was a reopen audit since it is obviously not opinion based. – Agave

I kind of agree, the opinion based ruling is out of context - answers are based on true facts. – Metrify

Answer 1

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

Discarnate

Correct as of meteor 0.5 – Metrify

Just pointing out that accounts-ui is actually not powered by twitter bootstrap, though it can be used in combination with it. – Overscrupulous

Insecure by default. Yikes. – Garble

@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. – Robbery

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? – Sello

@Sello but upon use and execution of those from console, it will throw an access denied error. Check it out. – Asthenopia

Answer 2

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.

Kierkegaardian

Also se this thread on Quora with an answer from one of the Meteor developers: quora.com/Meteor-web-framework/Whats-cool-about-Meteor/answer/… – Paradiddle

@Meador the link is broken, could you update it please? – Yorkist

@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 – Meador

Answer 3

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.

Pinfeather

This is completely true as of Sept 2012 – Metrify

Answer 4

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

Businesswoman

The solution would be to save your code in the server/ folder - this way it doesn't get pushed to the client. – Metrify

DrM, please see docs.meteor.com/#structuringyourapp — sensitive code does not need to be delivered to the client – Corporate

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. – Businesswoman

Hmm, strange, testing seems to be fine, will update answer – Businesswoman

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. – Businesswoman