4 ms·
There are two main types of security. Object-level, and app-level. Each object gets access controls that are similar to ACLs in Unix systems. That provides for
by lacker 14y ago
There are two main types of security. Object-level, and app-level. Each object gets access controls that are similar to ACLs in Unix systems. That provides for the sort of security that separates different users' data from each other. On an app-level, you can also control per-class which operations are usable. For more detail, see:
https://parse.com/docs/data#security https://parse.com/docs/data#security
You should be able use these in combination to secure your app. If you have more specific questions about how to secure a particular use case, drop us an email at feedback@parse.com and we can help figure something out.
- peripitea 14y agoI still don't get how I, as a malicious (or curious) user with some form of write permission, would be prevented from doing the equivalent of opening up Firebug console and typing while(true){var p = new Post(); p.save();}
- equark 14y agoWhat prevents you from doing this with ajax post on every existing website?
- jgannonjr 14y agoThis is true, but at least if you control your own backend you can do some sort of rate limiting on the server side
- peripitea 14y agoServer-side logic. The difference is that traditional data flow is UserControlledCode (i.e. client-side JS) --> MyServer --> DataStore, whereas this is UserControlledCode --> DataStore. In practice you may often choose not to have the code in MyServer do anything beyond act as a pass-through, but not having that option at all seems scary. The only recourse I see is things like database schema constraints (e.g. max posts per user = 10), but that doesn't really solve the problem. Edit: And I should add that the problem isn't just a user creating new many objects. The problem is that without code controlled exclusively by me somewhere in the middle, business logic (i.e. anything not codified in your database schema) becomes unenforceable. E.g. pull up firebug and type player.levelUp(); player.save();. Now there may be some subset of applications where business logic like this is completely unnecessary, but I can't think of many.
- fooandbarify 14y agoI can't see it working well in a game scenario, but the vast majority of CRUD apps out there could be safely implemented using Parse's security model (as described in lacker's link).
- bonaldi 14y agoThey use a game in their JS documentation! And as they wrote it it's totally vulnerable to the user incrementing their own score. It's not just games, either. As soon as a client-server solution gets beyond utterly trivial it becomes hard to see how you'd do it without server logic. Take another example described in lacker's link -- a messageboard post: the ACL defines whether or not a user can make a new post, but what controls the content of that post? What forces HTML tags to be dropped, or limits the number of images in a post, or the size of the post, or checks the domains of links, or prevents xss, or rate-limits a user? Some of this you can do by treating your entire database as "dirty" and sanitising things on the way out, too, but that doesn't come close to squaring the circle.
- skilesare 14y agoI think this is the answer from their docs: -------------------- All operations are still possible when authenticating with the master key via the REST API. As a developer, this lets you manage any aspect of the data. For example, you can delete private messages via the REST API even if they are private based on the ACL. ------------------------------------ So you really need a intermediate and secure server if you are doing something that needs to be trusted. To have a game completely offline would be a recipe for disaster. You'd probably want to push events into the users profile, have the game ping your server to tell it that there are events waiting, Pull those events on your server and then increment the score. On your server you can have sanity checks and do cheat detection.
- bonaldi 14y agoYeah -- but I think a service that offers to handle all the server stuff for you that also requires you to set up a server has missed a step somewhere.
- fooandbarify 14y agoPresumably it is exactly the same as in any other web application--the save method is using an HTTP request under the covers, which must be rejected if the user is not authorized to perform that action.
- jimmar 14y agoI don't think it's just a matter of authorization. I think you would have to use something like anti-forgery tokens to prevent automated scripting of http requests.
- deleted 14y ago[deleted]
- deleted 14y ago[deleted]