I am working on a Meteor application that uses Iron Router. We have a login page in our application. Even when the user is not logged in, if I call the below code on developer console as un-authenticated user:
Router.routes
It gives all the routes and the respective paths. Is there a way to disable access to these paths or do I need to push these end points in the server code ?
Everything you define on the client is visible on the client. So is all the routes definitions and routes logic, too. In production code this will be obfuscated but it's still there.
If you are concerned, that clients can read your routes, then you should be more concerned about the fact that it concerns you. Sounds a bit confusing but the point is: you should double check each data published to client via publications or manipulated / created via methods on server. If your backend is robust and secured as much as possible (100% will never be possible), then you don't need to care, if clients can see which routes exist and get access to them.
An example:
Bob found the route /admin and disabled the router's triggers to redirect him if he is not Admin.
Now Bob could see all data, that Admins can see. To prevent this, you may check in the publication if Bob has the role 'admin' on don't publish to him if he's not admin.
Ada also found this way to the Admin panel and wants to create a new user. Because your server method for creating new users is a ValidatedMedthod that checks if Ava has the 'admin' role it will fail to create a new user, because Ava is not an admin.
Conclusion:
Preventing access on the client side is just UI Magic bot not secure at all. Simple tweaks, however on the server side will help you to sleep better.
More help:
A good way to get started is to read the Meteor Security Guide:
https://guide.meteor.com/security.html
There is also at the end a security checklist, which I just cite for completeness and SEO reasons here:
- Make sure your app doesn’t have the insecure or autopublish packages.
- Validate all Method and publication arguments, and include the audit-argument-checks to check this automatically.
- Deny writes to the profile field on user documents.
- Use Methods instead of client-side insert/update/remove and allow/deny.
- Use specific selectors and filter fields in publications.
- Don’t use raw HTML inclusion in Blaze unless you really know what you are doing.
- Make sure secret API keys and passwords aren’t in your source code.
- Secure the data, not the UI - redirecting away from a client-side route does nothing for security, it’s just a nice UX feature.
- Don’t ever trust user IDs passed from the client. Use this.userId inside Methods and publications.
- Set up browser policy, but know that not all browsers support it so it just provides an extra layer of security to users with modern browsers.
Useful packages mentioned in the answer: