Thanks for suggesting.

I think this would be a useful addition to Parse Server. It would also fall in line with our strategy to improve Parse Server's security guidance.

when a developer new to parse looks at a Parse Object and sees no ACL set, it might be assumed that no one can access the object, when the inverse is true.

I agree that this assumption will increasingly become true in the context of how security is approached by large cloud service providers.

Some thoughts:

• The setting could be more granular per class, e.g. with a regex definition for which classes which settings apply by default. If this is not part of this PR, this should be kept in mind as a possible future enhancement when designing the solution.
• The default could be set to private (only the user who created the object has access to it). This would be a breaking change, as developers would have to manually set the default to public. It would be part of the current strategy to make Parse Server's default security more restrictive as guidance for developers.
• A public default setting should cause a security check log entry.

The setting could be more granular per class, e.g. with a regex definition for which classes which settings apply by default. If this is not part of this PR, this should be kept in mind as a possible future enhancement when designing the solution.

I might need some assistance on the regex definition stuff. My regex skills are to be desired.

The default could be set to private (only the user who created the object has access to it). This would be a breaking change, as developers would have to manually set the default to public. It would be part of the current strategy to make Parse Server's default security more restrictive as guidance for developers.

This could also apply to default CLPs for Parse Server, perhaps we assume requiresAuthentication:true if no CLP is set? Or maybe we could have a defaultCLP option.

Would you be open to adding that if an object has no ACL set, interpret that as public R/W false?

I think the only challenge with this is for users getting started and playing with a development server, if they write some code such as:

const note = new Parse.Object('Note');
await note.save();

And then later, note.find() will effectively return 0 objects, which for a new developer, it might be confusing as to why nothing is showing.

Alternatively, we could add to the documentation for Parse Objects a bold message that states "Objects can be publicly accessed by anyone, unless ACLs and/or CLPs are restrictive. Consider how your data can be publicly accessed before deploying to production".

I might need some assistance on the regex definition stuff. My regex skills are to be desired.

You can take a look at the Idempotency regex logic that parses for class names. It's basically the same logic needed here.

This could also apply to default CLPs for Parse Server

Yes, we can think about that, maybe leave that for a separate PR to keep this one simple. But it's something to keep in mind when designing this PR.

Would you be open to adding that if an object has no ACL set, interpret that as public R/W false?

We can discuss that but at first glance it seems to be a fundamental change that could require complex migration efforts for developers, and within Parse Server itself. It basically means to migrate existing data, which is something that requires a very convincing cost/benefit ratio to be considered.

And then later, note.find() will effectively return 0 objects, which for a new developer, it might be confusing as to why nothing is showing

Security awareness is something we want to established for new developers of Parse Server. The guides and example codes would need to be adapted to reflect that. For a simple playground environment, the developer can always set the default object ACL public read/write which would cause a security check log entry as a reminder to disable it later on.

We can discuss that but at first glance it seems to be a fundamental change that could require complex migration efforts for developers, and within Parse Server itself. It basically means to migrate existing data, which is something that requires a very convincing cost/benefit ratio to be considered.

That is a good point. So, if I understand correctly, the PR shouldn't modify any existing find logic, just purely save logic? And if no ACL is set on the object, set the acl in accordance with config.defaultACL (defaults to private)?

The label type:feature cannot be used in combination with type:improvement.