Default CLPs for new classes to disallow public read/write

[johanarnor]

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

The current behaviour when adding a new class via the Parse dashboard is that new classes are created with public read and write permissions in the CLP. This introduces the risk of forgetting to change them which in turn can lead to data leakage and data corruption.

I've searched in the documentation and previous issues, but I have not found a solution or a similar issue discussing this. If there is, please point me in the right direction!

Feature / Enhancement Description

I think the best way would probably be to always default to no permissions at all, and let the developer choose what read and write operations to allow and for what role. Sure, it's an extra step compared to public read/write which allows everything, but it's at the same time much easier to adapt your code in the beginning to use either sessionToken or masterKey where appropriate, rather than changing the permissions a while later and going through your code to find the places where you might have missed it.

If it's not feasible to have as a default, it could be added as a configuration option.

Thanks in advance! 🙏

[parse-github-assistant]

Thanks for opening this issue!

[mtrezza]

Is that a Parse Server or Parse Dashboard issue? From your description I'd assume a Parse Dashboard issue, or is there a default behavior when creating a new class in code that you'd like to change as well?

[johanarnor]

Hi and thanks for your reply! I think this can be solved in a few ways with different severity regarding the breaking nature of the changes.

• Include a default CLP from Parse Dashboard. As a developer it would still be possible to create public classes by misstake from code though.
• Set a "private CLP" if it's not included when creating a class in Parse Server.
• Treat a missing CLP as a "private CLP" for all classes. This is of course the most breaking alternative, since it will change permissions on already created classes. But also the most secure since I suspect that many users of Parse Server can have public accessible classes without thinking about it. This is what we did for our deployment with a simple code change of the following line

  parse-server/src/Adapters/Storage/Mongo/MongoSchemaCollection.js

  Line 78 in c604657

  const defaultCLPS = Object.freeze({

As I mentioned before this could also be behind an environment variable or something as well.

What do you think?

[mtrezza]

Any breaking changes that involve data migration (as opposed to just app code adaptation) come with a significant cost for developers that would have to be justified by an even greater benefit. I don't see this as given with the facts currently known about issue at hand.

I'd say that a solution can either involve the Dashboard creating a class with a more restrictive default CLP, or the code for creating classes getting a more restrictive new default behavior.