Your fears are quite fair. The default permissions for the Parse database are configured for easy development, so without further configuration it is almost trivial for anyone who drops all of your users. Unfortunately, real security requires quite a lot of effort, when different default values will immediately make many applications more secure.
See this blog post for an example of how simple a user dump can be: https://www.webniraj.com/2013/08/01/using-the-parse-javascript-sdk-be-careful/
ACLs for each object cannot provide access that has been denied by class level permissions, so even if you do not want publicly accessible user data, open class level permissions for the Parse User class must be configured in a way that SDKs can interact with them:
- In order for the client to update the current user, a public "Get" is required.
- In order to register a user, a public "Create" is required.
- A public “update” is required to set a username and password.
These public permissions are then limited by the user ACL. The built-in User class is assigned an ACL by default with public reading and private readwrite (for a specific user). I don’t need to read public read for users, so in the hookCase Cloud Code I changed the ACL to a private readwrite. I didn’t even need private write access, since I was going to use Cloud Code for custom updates, but the ACL always returned to private readwrite.
I didn’t need the ability to search for other users, so I turned off the public Find function, which is a quick solution so as not to delete all your user information. Although it is less risky and requires an identifier for a specific object, the public "Get" can still be abused, so I removed the public read from the user ACL.
UPDATE:
Configuring class-level permissions (CLPs) to publicly authorize operations does not necessarily mean that any data is publicly available. These CLPs determine what operations can be performed for each database class from any client SDK (which means "public" - using the "private" master key can still override everything). Then, the ACLs for each object determine which users / roles are allowed to read and write this object. I highly recommend reading my 5-part security blog post to get an idea of the interactions between the CLP and the object-level ACL: Parse Blog: Security
CLPs allow you to block client access to entire classes in the database. For example, I have a class that is used only by cloud code, so I disabled all CLPs (preventing these files from being read or written to the client SDK), and then the cloud code uses the master key to override CLP for use on the server. I also have client interface, but objects are private to the user. They have the publicly available Get and Find CLPs, but are protected for the user with a private ACL for reading and writing only for that user.
Parse has also added a “pointer permission” recently, which looks useful in restricting access to the “owner” of each object, but I have not personally used them: Parse pointer permissions