Hello guys.
Will you see this video? What do you think?
Edit: I know Parse and I have no doubts about its security.
I posted the video to share how they are talking about the platform, pointing out problems that I don’t think exist.
I already left my deslike in the video
What do they think: The problem with Parse: A low-code server that endangers over 64,000,000 users
I’m currently using parse. I have used Firebase before. I must say parse server is pretty secure if you know what you do. I mean if parse is not secure, then firebase is more unsecure than parse.
Yes all data is public. But you have CLP and ACL. If you read some documentation, you can secure your data easily. If you dont lock your car and your car gets stolen, thats not fault of car manufactuarer.
And about files, Yes there was a security issue back then but now we have file triggers. And we can log every file upload and take action.
I say parse is pretty secure.
What you are about to read is only my point of view.
First simple answer: Parse is totally secure
Like a sports car, Parse is a very powerful backend as a service, but if a developer wants to do anything with it he can do it.
Keep it simple:
From my point of view it’s a video sensation since it’s very easy to attack a solution as a parse that has a dynamic security configurable by the developer. The video doesn’t mention or demonstrate any real security flaws that could endanger other users’ data.
PS: A video saying “Wordpress: A solution that endanger 1.000.000.000 users” is at the same level aha
I have known Parse since the beginning and I have no doubts about security, if well configured.
The guidelines are in the documentation.
I shared the video because I thought it was “opportunistic”. For me, the guy wanting views for the video on youtube.
The problem is not with Parse, but with the developers.
Final answer if the Youtuber see this:
An improvement on the documentation with a better security awareness could indeed be welcome, instead of such a video maybe a pull request to our documentation from this famous Ben Heald would have been more constructive and more intelligent, but then it’s less views ahahha
@RodrigoSMarques thanks for sharing this funky video 
But to keep the community forum dedicated parse developers with constructive content i can suggest to remove this post @Tom, @RodrigoSMarques what do you think about removing this topic ?
It’s fine by me.
I think that highlighting the Security documentation would be welcome.
The video seems to be referencing the default settings. It’s fairly easy to enable the necessary settings to be protected. If needed, you can look at how I setup CLP and default classes here: https://github.com/netreconlab/parse-hipaa
The main branch easily passes the tests in the script from the YouTube video 
. The docker image above is free to use by anyone who needs secure classes by default, though most of the image maybe overkill for some.
To be fair, the person in the video also mentions vulnerabilities on Firebase, but the talk is about Parse
@Moumouls it might be fair to keep and maybe people can post how they address the issues mentioned in the video?
@cbaker6 agreed for constructive feedback, may be we need to just change the title to “How to improve default security” ?
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.
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:
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.
@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
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.
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.
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
It looks an awesome first move
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?