CODEWITHSUNDEEP
javascriptsecurityparse-platform
adamdport
adamdport

Reputation: 12633

What do CLPs on the Parse _User table do?

Parse.com JS documentation states:

The Parse.User class is secured by default. Data stored in a Parse.User can only be modified by that user. By default, the data can still be read by any client. Thus, some Parse.User objects are authenticated and can be modified, whereas others are read-only.

Specifically, you are not able to invoke any of the save or delete methods unless the Parse.User was obtained using an authenticated method, like logIn or signUp. This ensures that only the user can alter their own data.

By default, the _User table has checkmarks next to both Read and Write. Sure enough, a quick test shows that I can query for and fetch other users' data, but I cannot modify it.

Am I correct in thinking that

  1. The _User table is special and does not follow conventional CLP rules?
  2. The only impact of unchecking Write would be the prevention a user from editing himself?
  3. To secure data in the _User table, is it therefore sufficient to simply uncheck Read?

enter image description here

Upvotes: 1

Views: 159

Answers (2)

Mo Nazemi
Mo Nazemi

Reputation: 2717

1-Yes, the User class behaves a bit differently. Read Security Edge Cases section of the documentation.

2-No, it will disable Create permission too which means no user can sign up or update its data.

3-Depends on what secure means here. The user class is kind of write protected by default, so users cannot write over each others data. However they can search and read each others data. To avoid this disable Find permission. Delete permission is also better be ticked off.

Make sure to checkout Advanced security tab to see all permissions instead of only Read/Write

Upvotes: 2

Jake T.
Jake T.

Reputation: 4378

Click that little gear and move the switch to advanced and you'll see some more options.

There is also an ACL, which is attached to each object. I recall seeing a flow chart on one of the Parse guides that showed first an object's request must pass the CLP, then the ACL before it is accepted. So, if it fails the CLP, it won't pass the ACL, even if it's set. However, I think in practice I've found that not to be true, you'll have to test a little bit.

The _User CLP is set up differently by default so that other users can not write over each other's data. You can change that if you'd like, though it isn't advised. In order to change another user's values from your current user, you would ahve to call a cloud function that calls Parse.Cloud.useMasterKey();, which bypasses all ACL and CLPs. Note that this can not be used in beforeSave triggers, and I imagine beforeDelete triggers.

When you expand to advanced settings, you'll notice read has a get and find option. Get means that if you know the object id, you can get the object. Find means if you create a query, it can be returned by a query without knowing the specific objectId. For Write, you have create, update, and delete. If create is checked but update isn't, you can create objects from the client side and set any initial parameters before you initially save it. Once you make the first save, you will not be able to update that object without the masterKey. Delete should be self explanatory.

Hope that helps a bit. Let me know if you want anything clarified.

Upvotes: 1

Related Questions