9 ms·
The client API requires that you provide it your app's global credentials. These are likely to be baked right into the code, so can be easily extracted from the
by scotth 15y ago
The client API requires that you provide it your app's global credentials. These are likely to be baked right into the code, so can be easily extracted from the binary. It looks like the entire datastore is mutable/queryable after authentication by default. Privileges can be revoked on datastores after creation, which is obviously not ideal since it limits your app's capabilities.
In its current form, this is inappropriate for all but the most basic use cases.
- scotth 15y agoWhy am I being downvoted? As responsible engineers, we should be deeply suspicious of anything coming from the client. This product flies in the face of that wisdom.
- deleted 15y ago[deleted]
- lacker 15y agoHi Scott. Just to clarify, the client API does not use the app's global credentials, but the client credentials which have their access limited in several ways. One is the per-column access configuration, which lets you set up objects where access is restricted to users with the relevant token. The other main security restriction is user-based authentication, which ensures user data can only be updated by a client authenticated as that user. The combination of these security methods handle a lot of use cases, and we're always looking to add more security functionality to make more use cases work securely. If you have a specific application in mind, I'd love to chat with you about how it maps onto our security model. Feel free to drop me a line at kevin@parse.com.
- deleted 15y ago[deleted]
- scotth 15y agoI do see "class" level permissions, as I mentioned in my previous post, but nothing suggesting that finer grain control exists. I do see that you can store data on the authenticated user, which is a good start. And if better security is something that's in the works, that's great. I'm not looking to give you guys a bad name. I just saw this being talked about in the startups I work around, and felt as if some of the less experienced developers were not considering what implications using a service like this might have. It's convenient, I'll give you that -- but instead of facilitating good security through its APIs, it obscures the need for it altogether. And from what I can see, it would be difficult for you guys to encourage good practice without being heavy handed. Let's just hope your users are smart about how they use your product, because I'd hate to see what effect a few breaches might have.
- lacker 15y agoThat's a good way to describe our goals with Parse security - to "encourage good practice without being heavy handed". We are always looking for ways to make Parse easier, including security, so we definitely won't stop with what we have now. If you have specific suggestions feel free to drop me an email.