janl
commented
10 years ago @aymanfarhat heya, good questions there. In short, there is no “solution”, because we don’t think this is a problem :) — Since data is always scoped to a single user, all “damage” they can do pertains to their own data. That’s analogous to how, say, you could reverse-engineer gmail and wreck havoc that way.
Two more considerations:
- You can set up server side validations, if you feel like it, so only well formed objects can make it back to the server. Currently this is a manual effort (use CouchDB’s validate_doc_update feature), but could easily be a plugin that someone (or you! :) could build.
- With sharing plugins, extra care needs to be taken, so that tampered-with object don’t make it to other users, but the sharing plugins can take care of that.
aymanfarhat
Hey guys, I love the concept of this project. I haven't checked the source yet and I am wondering how do you go about dealing with securing data that is sent to the server right from the client?
As in what could prevent a user from reverse engineering the code to understand the database, and then issue queries such as updates and delete, right from the browser's console that get persisted to local storage and then synced with CouchDB?
I will be looking further into the source to understand more. I assume you already found a solution to this, but would be cool to have a page in the docs explaining how security in hoodie works. Thanks!