I’ve been playing aroung with Meteor for a month or so, and there’s something that keeps bugging me. EVERYTHING is loaded on the client, wether anyone is logged in or not. I really don’t want curious users to inspect my subscriptions, my schemas, and everything, without even getting to log in to the app!!
I successfully loaded my collection’s schemas only on the server, but now, I’m facing the fact that I won’t be able to NOT load all my templates and stuff on the login page.
Am I paranoid? Is this a regular thing? Aren’t you guys concerned? What is going on?
Removing autopublish package doesn’t solve my problem (also, I removed it a long time ago).
In fact, removing autopublish package will only filter the data that receives the client, “forcing” you to use Meteor publications and subscriptions, and I’m already coding that way.
All in all, I’m still concerned on users being capable of inspecting my collections schemas, my templates, my client routings WITHOUT logging in the application :S
So I’ll ask my question again. Am I being too paranoid over this?
I think you are being paranoid. First of all, a user (anonymous or not) only sees the data you allow them to see. Your database schema is basically json, so where is the difference compared to a REST app that gets data from the server? An anonymous user could inspect that as well.
Just because the user can see your schema, or what you disclose of it, doesn’t mean they can modify it, as long as you did the security right by following the patterns outlined in the meteor guide.
I’m maybe wrong, but I think implementing a REST resource doesn’t force you to publish all your model data, and certainly doesn’t expose your schema. Also, a REST resource can be secured by multiple ways, it hasn’t to be public.
On the other hand, I’ll agree with you with the fact that following meteor’s security guide should be enough, but it doesn’t feel right: I’m exposing information that an unauthorized user shouldn’t know about, even if it’s the templates of my app.
Finally, I know exposing my schema doesn’t mean they can modify it. I’m just saying I feel it’s information that shouldn’t be published, information that could be used to analyze the app and search for security holes.
My English is not great, maybe I’m being misunderstood :’(
You’re English is fine. In most cases you’re indeed probably being slightly paranoid, exposing a schema doesn’t tell anything about the actual data, without the data I don’t see real security issues popping up, but in some niche cases you might indeed want to restrict your source code to anonymous users. There are so many possible ways to achieve what you want but they all rely on modifying some of the core concepts of meteor.
Some ways on the top of my head:
Don’t have schema’s on the client-side, do all data manipulation through server methods, since server code doesn’t get exposed the schema’s can live safely on the server.
Implement server-side rendering only: This kind of defeats the purpose of meteor, but it is possible.
Lazy-load templates as necessary: I remember an atmosphere package that allowed you to load resources from the public and private folder, so you could inject resources depending on the route or a certain action on the client-side. (https://atmospherejs.com/numtel/lazy-bundles)
Again I want to stress for 99% of apps this is way overkill and I’m not even sure meteor is recommended if security would be your number one priority. As is meteor is quite secure, but I wouldn’t build a whole banking platform on it, cause in that case I’d build it on vanilla node without relying on many external libraries.
He’s not paranoid.
This is a known problem with the Meteor build system, all client code is sent indiscriminally to every client, even those that are not logged in.Which also means that if you have an admin UI with settings capabilities you don’t want your regular users to see, this is also not possible.
Incremental/on demand loading has been one of the most requested feature on the old Trello Roadmap, some years ago. I fear if you need this, you will have to use Webpack…
If you want to hide your schemas, you can include them only on the server as suggested, then also include a small JS file on the client which will just define the collections without the schemas like this:
Tasks = new Mongo.Collection('tasks');
Pages = new Mongo.Collection('pages');
// etc...
This will work only if you don’t do any kind of data manipulation on the client, though. You can still query those collections just fine, because schemas are not really required for this.
For me personally it’s not a problem that a user can inspect my templates, because if the methods are properly secured then he cannot do anything with that knowledge. The only problem for me with this setup is that if you have many templates then it would be benefitial to lazy-load them so the initial loading is faster. But I guess this is not really a Meteor problem, but the View layer problem. For example I’m using Framework7 for my mobile app and it loads the html files on-demand instead of compiling them into the app at build-time. Maybe the same could be done for Blaze or React?
Thanks for your answers! A bit more of explanation on my side could have been of help: I’m trying to build something like an extranet to test Meteor. So you can see why I ran into these security issues.
@nlammertyn
I already defined the schema on the server, and apply all the validation there, but my concern is with all the rest of the code. I thought about implementing server-side rendering, but saw that too hacky. But i’ll certainly be looking into numtel:lazy-bundles, looks good at a first glance.
@vjau
I already saw the feature request on Trello, but MDG stated clearly they wouldn’t be implementing this, as it would challenge Meteor’s core. And that is totally acceptable.
at M4v3R (can only mention two users )
Same answer as the one made to @nlammertyn. Also, I will never trust the user, never They can do all of nasty things with knowledge. “Give somebody an inch and they’ll take a mile”
Thanks for all your answers again. After considering a bit, I think I will try to secure the access directly on the webserver (in this case nginx): proxying, tokens, don’t really know right now. If that fails, I will have a closer look at numtel:lazy-bundles as suggested by @nlammertyn.
I’m not really seeing the problem. As long as you secure access to the actual data and its manipulation methods, what do you care if someone snoops around in templates?
You’re saying that they could “do all sorts of nasty things”. What things would that be exactly?
I mean, security is all nice and well, but it needs to solve actual problems. Because otherwise you’ll only shoot yourself in the foot. After you’ve already shot your other foot.
If you properly secure your data and your manipulation methods then there’s nothing the user can do with any info about templates.
And if you don’t secure it properly then you’re screwed regardless. Visible templates or not.
Plus, hiding the logic from your users is really security through obscrurity, because if you have a flaw in your code and a really dedicated hacker, he will find the flaw regardless if you make your code available or not . So really the only way to be secure is to write secure code. I know it’s harder than it sounds, but there’s really no other way and just hiding your stuff from the adversary won’t get you far.
I personally see this as an advantage, because it contantly reminds me that I have to be extra careful. I know I cannot afford to leave holes in my code so I put extra care to make sure it’s secure.
Indeed. And there is something like “too much security”.
a) It either results in an unusable product. Like we have in Germany, where the data privacy security obsession makes dash cams unusable because a judge seriously demanded that you only switch on a dash cam when you actually need it.
“Oh, I’m about to have an accident! Time to switch on the cam!”
b) Or it results in new and exciting security holes because of unexpected side effects. Like those “your password expires in 90 days!” security settings. Which are rubbish because now everyone will use an easy to remember password and simply add a number at the end, incremented by one every time a password change is mandated.
I understand your opinion, but I think you are not getting it. It’s not a deal with security itself, it’s with wether you are authorized to see a content or not. And certainly, an unauthorized user shouldn’t be watching at my app layout. It’s as easy as that. It’s like publishing your social life on Facebook without setting privacy options. Would you do that?
No, it’s not . You’re comparing publishing potentially sensitive content to publishing HTML code for the structure of your app, which is next to useless without the actual data, which user who is not logged in would not see.
It’s similar if you were to develop a desktop application - would you be concerned that someone can actually disassemble your binary and read assembly of your code? You can try to obfuscate it somehow, but a person who is dedicated enough would still be able to crack it open.
I see this discussion won’t have an end, as it is a matter of opinion: I don’t like showing the entire app in a login page, wether you guys are willing to.
I too understand your concerns, but it’s not a matter of opinion. As @diaconutheodor indicates it’s a matter of fact that javascript in the browser is completely visible (any JS browser app, not just Meteor).
)
They can do all of nasty things with knowledge. “Give somebody an inch and they’ll take a mile”
. So really the only way to be secure is to write secure code. I know it’s harder than it sounds, but there’s really no other way and just hiding your stuff from the adversary won’t get you far.
. You’re comparing publishing potentially sensitive content to publishing HTML code for the structure of your app, which is next to useless without the actual data, which user who is not logged in would not see.