[sespindola]

This. Most tutorials of Backbone/Ember js apps I've seen have thin backends that commit any json objects the clients send them.

Data sanitization and validation on the backend should be as thourough as that of the client, if not more.

[StavrosK]

Who in their right mind does data validation on the client? However, there are (very easy) ways to store data on the client and be sure they haven't been tampered with. Just HMAC it along with a secret and check it next time.

[tfb]

My startup uses node to handle all database operations and essentially only serves JSON via AJAX, while the most HTML it sends is basically <script src="script.js"></script>. The entire app itself along with user-generated content depends on a few large (highly variable) objects sent as JSON where the DOM is manipulated based on this minified data.

As a bit of a backup measure (mainly to prevent XSS), the client-side javascript sanitizes (which is what I believe you partly mean by data validation) all objects sent to the client when as they receive it. So anyone using the intended client-side script should never be susceptible to XSS.

But if by "data validation" you were referring to concepts like whether or not a user has permission to access/modify some part of the database, of course that is checked server-side.

[StavrosK]

The latter is more what I meant, yes. Basically, we all know you shouldn't trust the client ever.

[AdrianRossouw]

Well, because the same code runs in both places, you end up with a situation where you are _also_ running the validation (most of it) on the client.

The models can (and should) still be validated on the server before you actually save it, but this is child's play. There is a certain category of validation that can only happen on the server too, like 'has this username been taken already?'.