What are the recommended permissions for the Users table for a typical app?
Would disabling RETRIEVE permissions for all users except ServerCodeUser be adequate? That way a hacker with the SDK could not retrieve or find() other users and their objectId’s & email addresses, etc.
That documentation tells me what I can do, but my question is more about what I should do to protect my database and my user info from hackers.
For a concrete example, let’s say that I want a mobile game where users register and log in and all I want to do is store the number of virtual currency coins that each user has in the users table.
I’ll assume that hackers can extract the Application ID and subdomain from my app one way or another. This means that they could use the SDK to log into their own account and set their coins to be whatever amount. That’s okay for now and I could develop other strategies for dealing with that - but the point is I’m not overly concerned about that aspect.
If the Users permissions are set to GRANT ALL, then the real problem is this: any hacker could log in, get a listing of all the other users, including their email addresses to sell or spam, and even (let’s say) maliciously delete all other users (I think?!).
What is the least restrictive set of permissions I would need to set on the Users table (and/or Roles) to prevent a bad actor from obtaining the email addresses of other users and manipulating or deleting other users?
application ID and subdomain are not secret or sensitive data - it just identifies your app. Receiving them is like getting https://mail.google.com from your mail - it doesn’t give anyone the chance to get your emails, right?
To ensure the security of your data, there are several levels in the permission system (as described in the documentation). With the help of their combination, the desired behavior is configured, including the one that you described.
However, the method that you suggested is also working and popular - restrict all roles except for the ServerCodeUser role, and work with the API through business logic (aka cloud code).
Okay, sounds like I’m on the right track. I made two additional changes to be hopefully secure by default for my simple backend needs:
Under Users > Security Roles I denied FILES > [Delete,Write,Permission] for all roles except ServerCodeUser.
Under Data > Users > PERMISSIONS > ROLES PERMISSIONS I denied the PERMISSION permission for all roles except ServerCodeUser so that users can’t undo the change in #1.
I think I’m good to go but LMK if you have any further recommendations!
Glad you figured it out. Your logic looks correct.
I can also advise to create a New Custom API Key and configure it according to your needs to prevent the CloudCode API Key usage (using the CloudCode API Key on the client is not secure).