According to what I just found out, we can’t load the template html and js files selectively. We can’t restrict the loading of Admin area’s files for non logged in users. Isn’t this a security risk?
Nope. As long as on the server you’re checking the validity of any requests to methods/publications/end points to make sure the user is permitted to make those requests, there’s no security risk in sending down code for an admin area. Reading through the code to see what the admin area looks like doesn’t put anything in question. HTML, CSS and JS are always public and should be assumed as visible to the client. As they always say, “never trust the client”.
3 Likes
Your right “never trust the client”, that’s why im a bit scared.
You can keep your server side methods on the server via special directories
What files are you talking about here? There shouldn’t be any sensitive data in your html/css and you can hide js, so it should be ok.
‘never trust the client’ means validate everything that’s coming from the client.
Sending more than required down the wire is more about loading time and there are a few SSR related packages to help in this area too (just search for SSR in forum or atmosphere).
1 Like
Why not make the Admin app a separate meteor app that connects to the same DB as the client?
2 Likes
Ah yes that’s also a good way. Validate everything before accepting.
Hmmm yep thats also will be a good idea. Im new to meteor. So may I know how to do this? A hint?
If you set everything up properly, there is no security risk.
Aside from checking the validity of any request to methods and publications, as @efrancis already mentioned, I would also recommend to use the audit-argument-checks package which will warn you if you don’t check input parameters to methods properly. I’m also using aldeed:simple-schema and aldeed:collection2 to set-up schemas and validation rules for my collections, so invalid inputs will be detected.
Another common mistake is to pass the id of the current user to a Meteor method instead of retrieving it inside the method via this.userId(). This would allow an attacker to use another person’s id to retrieve information. So use user id’s as input parameters only if you actually need it and sanitize the returned values properly.
You should also avoid to put any “secret” information like API keys in code that will be run on the client side - unless you actually need them on the client-side. If you only need them on the server, put them in the Meteor.settings (i.e. settings.json file), which automatically ensures they can’t be retrieved form the client-side unless they are stored under the public key.
1 Like
Here’s a good article about using audit-argument-checks:
https://themeteorchef.com/snippets/using-the-check-package/
1 Like
Finally! I was looking for an answer like this. Thank you very much! I will look into the package audit-argument-checks right-away. Looks like in meteor we not only have to change our language but also need to change the ways we work and look at our apps 
1 Like
You’re welcome.
Maybe this link will also help, it contains links to more pages as well:
http://justmeteor.com/blog/meteor-security-fundamentals/
And yes, you have to change the ways you look at your apps when you work with Meteor. Especially, if you (like me) come from a more “traditional” way of developing web applications.
1 Like
Perfect thanks! Im coming from Rails
I understand what he means.
Even people that have no account can see what your app is about. I think it’s a problem.
1 Like
Yes, this might be a problem in some cases. I would love to see Meteor having a technology like web-pack to dynamically load portions of the app depending on certain parameters (like the user-role). This would also speed up the initial start-up, which is especially important on mobile devices. One might use the current hacks to integrate Webpack, but I’d feel way more comfortable if this was an offical thing from MDG.
2 Likes
But sadely i don’t think this is the plan.
But isn’t this an inherent fault with single page apps? Itself built on the systemic premise of html/js source files being visible?
If you go on gmail without being logged in, you won’t receive any code (but i guess you are redirected somewhere else when you log in).
When you go on twitter page, the page is loading/displaying progressively the differents parts.
1 Like
Twitter moved away from a SPA a while ago.
I don’t know about gmail, but I’m guessing that gmail is an ecosystem of SPAs that are delivered by routing and authentication.
1 Like
I really like to hear what the core Meteor team have to say about this. The real reason for not implementing a fix. There might be a good reason.
(galaxy ?) 
