What security mechanisms does Meteor have?

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?

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

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.

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.

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