There is a Back4App tutorial about parse server security. It shows how to secure parse server with using CLP. I’m currently using this method.
@cbaker6 sorry. I accidentally replied to you
Good idea.
I’ll change the title
I think the issues is because of the “developers” not platform. So, let me explain to the lazy developers how to fix this issues with just reading the platform documentation:
1 - Anonymous Users: on the Parse Server config just set “enableAnonymousUsers = false”;
PS: if you need anonymous users, so, read and understand more about the platform, but yes, you can have it safely.
2 - Class creation: on the Parse Server config set “allowClientClassCreation = false”.
PS: Why accept the client side apps to create Classes? Anyway with more knowledge can be safe too.
3 - Modify data of any instance: Just read documentation and set the basic ACL.
PS: Parse use the Class ACL before the object, so, even if the object has the “public access” but the Class ACL don’t, this object will not be public.
4 - File uploads: Parse Server have fixed this issue, “file triggers”, just read the DOCS.
About the video: “Almost of the ACL documentation are hidden on sub pages”, OMG man, are documented, the code are OPEN, just learn a tool before use is the basic of any development, the BASIC!!!
The documentation need explain to the developer that if he don’t set “private” on the content that he need to be private, and by default to help the developer to test and run quickly the platform, is an issue? Please!
And about the numbers of “exploited data” again is fault of the services maintainers, developers, not the Parse Platform that give you FREEDOM and POWER to allow or not this.
In the end my opinion about this video is that you don’t need be expert in “penetration” security, just use Parse Platform first time, you can test it on Docker quickly on your machine, hahaha, and done, you “hacked” the Parse Platform, hahaha.
As as front end developer perspective I think Parse was a great way to learn and have a good backend service… The rest is knowledge and experience, even if you can get some hosted alternatives, if you want to have sure about something go ahead and learn it, when is open source even better.
2 Likes
It is obvious that the guy wants to promote and have a stage for himself instead of helping on improve the platform. It is also clear that Parse provides all the features for the developers to protect their applications. But, the solutions he proposes make a lot of sense for me and I have actually thought about them for a while:
- Implement default ACL/CLP for all classes, specially the User/Role/Installation and other default classes;
- Implement upload control in the dashboard + security upload by default;
- A new session in the dashboard containing security warnings.
I’m in to work on these items if we all agree. Thoughts? I’d love to hear from @Tom @dplewis @Manuel @Moumouls @cbaker6 (just to mention a few) and anyone else that wants to contribute.
5 Likes
@davimacedo totally agree with you, we can make improvement here to set some default ACL/CLP and avoid a mis configured security on basic objects. If you are ready for a PR, it’s perfect 
2 Likes
Those improvements sound great. It may require a change in the flow of the guides or clear pointers about default ACL etc so it’s still easy to follow and get started.
1 Like
The ambivalence of Parse Server should not solely fall on the developer, but is also for us maintainers to be considered. Historically, hosted Parse.com intended to be easily accessible for beginning developers, but the industry’s security landscape has changed over the years and especially the open-sourcing of Parse Server puts additional challenges to developers in terms of security considerations when self-hosting. If we want to be an open community - also for beginning developers, we should not a priori assume a lack of knowledge to be rooted in “laziness”.
We can expect Parse Server to continue to attract developers who may be overwhelmed with the scope of security considerations. But even for non-beginning developers who are new to the product, the security specifics require considerable research effort. In some cases it may not even be documented as in the case of file uploads, I believe.
I support @davimacedo’s suggestions, all 3 are valid points and and seem to be an adequate response to the criticism raised by the video author. Especially a new security section in the Parse Dashboard would be a significant step to help developers identify vulnerabilities more easily and secure their Parse Server instances.
Finally I should say that I am more surprised about the emotional reactions in this thread than about the video itself. Open source implies transparency and open discussion. I believe our community is mature enough to properly handle critical comments, even if some may consider the narrative objectionable. The web is full of narratives and the sensical approach can only be to extract the facts from emotions and discuss which action to take. At best - as in this case - we can derive action points to improve the product and shine as a community that embraces and acts on criticism.
4 Likes
For the interim, would their be any interest in a simple log warning if env is production, for:
-allowClientClassCreation should not be used in production (link)
-we strongly recommend schema on the _User class
-we recommend restricting schema all classes (link)
-and any other easily detectable vulnerabilities mentioned
Maybe we could build a custom spec that works off the Parse Servers’ parameters, and then attempts a few common scenarios (such as write other users, signup with weak passwords, delete other users, classes with no ACL’s / CLPs, etc), and then warns the dev of the potential issue. It could also be a good way to template / introduce some developers into tests, as for me personally, I hadn’t considered writing tests for my own server until I started contributing here. Something like parse-server --security-test
2 Likes
It looks an awesome first move
1 Like
Thanks, I’ll work on it and see how I go with potentially adding it to the dashboard as well. Should the security check run by default if .env is not production? Maybe an option in server config for silenceSecurityChecks if the dev is aware of the openness?
I’d go with an option to disable the security checks.
Thanks to @dblythy’s PR this topic is picking up speed.
I think once the PR is merged, it would be good if someone from the core team would reach out to the video author and thank them for the critical security analysis and the subsequent discussion it triggered in our community. Once we have a nice dashboard view for the security checks, maybe we can motivate the video author to update their video or release another one. I assume improving security is - and should be - the single underlying motivation of analysis like these, so I would expect that both the author and our community can claim a win in demonstrating that this process works.
2 Likes
Here’s a blog @dplewis shared with me. It’s from the same author of the video. Some of the information is the same, but goes into some more details. It will be good to address as much as possible: https://healdb.tech/blog/parse.html
1 Like
@RodrigoSMarques thank you for this post, this has lead to some great improvements to Parse Server, such as:
- Parse Server restricts fileUpload to logged in users only
- Parse Dashboard can be used with 2FA
- Parse Server has the SecurityChecks feature which checks for common misconfigurations
Note that enabling these features does not guarantee security of data. With Parse’s flexibility, it’s up to you to make sure that data is restricted, and that weak points in your server stack are protected.
An example of a common vulnerability is returning a full Parse.Object that has been fetched with a masterKey from a Cloud Function.
Parse.Cloud.define('getObject', () => {
return new Parse.Query('Objects').find({useMasterKey: true});
});
This cloud function will return all objects to the user, regardless of ACL. This is just an example of how data security is in the hands of the developer.
Generally, I write my Unit Tests at the start of a project to cover common security protocols that I want the application to follow, such as:
- Ensuring users can’t query other users
- Ensuring users can’t edit other users
- Ensuring certain data isn’t returned from cloud functions / queries (making sure sensitive data is stripped out if required)
- Ensuring cloud functions only return the data that is necessary
We are continuing to work on Parse Server security and welcome any suggestions or ideas 
3 Likes
My english is not perfect but I would understand this the other way. Did you mean “allows” instead of “prevents”?
I have not found any flag in server options in the documentation. It the public upload blocked by default or is there undocumented option to setup? I would like to check that for properly setting it on Back4App service.
Thank you!
You’re correct, it’s a double negative. I’ve edited my comment.
These changes are on the master branch only, soon to be released on V5!
Perhaps to confirm my understanding, these will be activated by default and no entry in the config is necessary, correct?
Thank you!
Although we are hoping to continue to evolve Parse Server, we don’t want to force developers into time consuming changes. Breaking changes are a source of frustration for our community.
Public fileUpload is the only breaking change. SecurityChecks and MFA for dashboard will need to be activated manually. Although if you’re using B4A, you should already be able to use MFA on their dashboard, and your masterKey / databaseURL is probably already secure (as they are autogenerated).
I can’t find any docs on enableAnonymousUsers with the exception of the Parse Server API doc that only mentions that it exists.
I looked in the following locations for further explanation.
So when you mention lazy developers you must be referring to the ones maintaining the docs?
This is my first time using Parse so I like to read through the docs so that I understand how to use the tech and make sure I am not getting myself into trouble. I’m not going to read source code just to figure out how a certain config option works. Bullet point #1 in your post is the most information about enableAnonymousUsers that I have been able to find so far.