@sashko Why am I the user in the quote 
lmao
Those of you whose apps do not need strong security (and suggesting that I should not use Meteor if I want strong security) should look beyond your own current apps. Improvements in Meteor security will help all of us both directly and indirectly. It probably won’t hurt if your apps are given stronger security by the core framework. Also, who is to say that your next apps will not need strong security? If they happen to need it then you may be thankful that we are discussing it now and actions are taken instead of later when you do actually need it.
To those who say “do-it-yourself” - Meteor is marketed as a framework that makes cross-platform app development easy. It certainly is easier to develop real-time data apps in Meteor than in other frameworks. They’re also making hosting management easy with Galaxy hosting. If they could also make security easy then that would complete a lot of the big puzzle of app development. As a result, uptake of Meteor would increase, providing more revenue to MDG (as many would choose to use Galaxy), which would improve the viability of the company and therefore the framework on which we have chosen to develop our apps.
I am glad to see some good steps being taken lately, such as ValidatedMethod, the section on security in the new Meteor Guide, and that the guide recommends not to use allow / deny. It is a clear admission that a Meteor app with allow / deny introduces security risks, and the most sensible recommendation was to stop using it. I would even suggest to go further by deprecating allow / deny to force everyone to rewrite their code without it.
Roles should actually be part of the Meteor framework. It is strange that even though Meteor provides an Accounts system, there are no roles functionality. In order to manage the user accounts, roles are required (to at least create an admin user). I know that there are third-party packages, however something so important should come with Meteor itself. The most popular third-party package for roles is alanning:roles, however Pete Corey points to a vulnerability in the package in this blog post: Meteor Security in the Wild.
This leads to another issue, and one that has not yet been mentioned in the Meteor Guide. Third party packages can have security holes. No matter how much work we put into making our code secure, a third-party package with at least one exploitable hole can result in disaster down the line. I can already hear some of you say “you have to examine the code of all third-party packages”, but I think it’s fair to say that it’s a lot of work to do that. I think MDG should continue to focus on ways to prevent security vulnerabilities in both our own code and in third-party packages. e.g. like the ValidatedMethod, print errors or warnings if vulnerabilities are detected in written code.
MDG should promote security to be one of their core guiding principles, and this principle should also be communicated to all package developers, as so far many package developers have not placed enough importance on security, which can place apps that use the third-party packages at great risk. e.g. even aldeed (of autoform, collection2 and SimpleSchema fame) has not provided a way to filter subscriptions on the server in aldeed:tabular.
Just read that article - I don’t know why you’re worried about it. It’s not a problem with roles at all, more of a problem of passing user data from the client and expecting it to be secure. This is covered at length in the security article: http://guide.meteor.com/security.html#user-id-client
We can’t “police” the whole package ecosystem. To avoid that, we’re picking a small set of practices and packages that we can stand behind.
Maybe I’m misspeaking here, but I feel as though the use of packages is an inherent tradeoff. Of course, it may be a lot of work to ensure the validity/security of a package, but then again, you don’t have to write the code yourself…
The OP has a point. I also found it quite interesting that none of the bigger Meteor/Galaxy resources beginners tend to go to, makes explicit statements about XSS, CSRF, Clickjacking…
For example, those resources below only have sections on general security, none however tells you what you’d want to do/consider in order to not fall victim to XSS etc.
Actually they’re using meteor in some projects 