Hacker News Reader

Comment by aliakhtar | Hacker News Reader

I've read somewhere that a use-case of Meteor is to let you write your server-side logic in javascript, and then run the server-side logic on the client. Wouldn't that be clearly insecure, to trust the client with running server logic?

Also, this was accomplished years ago with Google Web Toolkit, which lets you write both the server & client in Java, and compiles the client-side java to very efficient, optimized javascript. That has the added advantage of letting you use a sane, strongly typed language, with all the productivity tools available for Java, and none of the quirks of javascript. http://www.gwtproject.org/overview.html

View on HN

The logic runs on the client only for optimistic UI changes (getting to the right state and displaying the right data w/o waiting for a server to reply). In Meteor this is called "latency compensation" and you can read more about it here: https://www.meteor.com/full-stack-db-drivers.

Meteor implements it in such a way, that app developer decides what logic is latency compensated and what is not. Furthermore all the actions validation rules still apply on this executed logic and if clients disagree with the server (the privileged environment), clients cannot harm the server state.

Querying your database from client javascript seems like a bad idea. Even if they're not real queries, you are exposing the internals of your system, db column names / queries, etc.

This is something that I've wrestled with when working with meteor, how do you execute privileged queries from the client? You can do a 'Meteor.call' to execute code on the server, but there is no way to shield the user from accessing the parameters used in the query.

Traditionally, you would use a cookie on the client to authenticate and trigger the 'privileged' query during the http request cycle. As far as I can tell there is no way to do this with Meteor. Another way to phrase it is there is no authenticated server-side state modeling the client.

In the same vein, there's no way to shield the user from accessing the parameters of a REST request. Which incidentally is easier to replay outside the browser than a Meteor.call().

After doing some poking it looks like you can access `this.userId` in the server-side publish and Meteor.methods functions. That's enough to prevent a lot of client-side tampering

How is this different to consuming a REST API and rendering client side?

You can only view & modify data on the client that has already been published.

Data that you don't publish / is server only, will remain so.

Why would that be a bad idea? Unless you are relying on security through obscurity, which you are hopefully not, that shouldn't create any threats?

Trusting the client with all things is a bad idea. Running stuff like presentation/layout/gui on the client makes sense. For some things, it makes sense to run the same code first on the client, but the again on the server (so not really trusting the client). Example: form validation. You want to run it on the client, to give early feedback. You need to run it on the server, because you can't trust client-supplied data. Makes your life a lot simpler, if you only need to implement the validation code once, even though you use it both on the client and on the server.

If you read the docs you will see it's not implemented in an insecure way. The core meteor devs are pretty brilliant people, creator of etherpad, svn core contributer, early asana employee, these people aren't dummies they wouldn't do something that silly. Such a dumb thing would have been called out way before 1.0 wouldn't you think? Maybe give it a moment of thought before you comment.

Well to be fair, even smart people can make mistakes and miss things. But Meteor is open source, so if the person you responded to is going to question the security model, they can look at the actual code and see if there is an issue. That's the best way to prevent security issues, looking at the code for bugs, mistakes, and assumptions.

> Such a dumb thing would have been called out way before 1.0 wouldn't you think? Maybe give it a moment of thought before you comment.

To be fair, I'm pretty sure the previous versions did have this issue -- it was just supposed to be ultimately fixed. I could be recalling incorrectly though.

It was fixed about two years ago in October of 2012, when they added the accounts system and allow/deny rules. Since then they've added additional security features such as the browser policy package.

Reply on news.ycombinator.com