I subscribe to the "End to End Web Developers" group on LinkedIn. Today, someone posted a question "Is Parse a Secure Solution". I typed up a nice long response in my Sublime Text editor and pasted it into the response field only to be rejected because it was too long. So, here is my entire response.

As the article you linked to mentions, "There are some obvious measures you can take to protect your data". Parse and it's brethren (Kinvey, StackMob, Backendless, Azure, etc) are no less secure than any server side code you develop in a traditional LAMP Stack.

Yes, there are API keys inside the client JavaScript. Those API keys are really nothing more than a means to distinguish which "app" the backend is meant to communicate with. Think it of, Parse hosts thousands of different apps. So, each client needs to know which of those back-ends to talk to. It's just like a URL. So, you have a traditional LAMP architecture using a URL. How's that any less secure than Parse's use of a keys? The bad guy knows your address. The bad guy knows Parse's address. Right?

"Anyways I thought back to what i have always heard which is using JavaScript as a direct go between for client and data is a no no" - This is meaningless. When you post a traditional form, doesn't data transmit between client and backend? On your form, do you not do some client side validation to avoid wasting bandwidth validating information? What's it matter what technology on the front end manipulated the data? In the end, HTTP is going to carry the traffic to your LAMP stack or to Parse, Kinvey, etc. All of that data is visible to a determined cracker regardless of what client-side code is used to prepare it. Your only protection here is https.

As far as the API being exposed (also demonstrated in your link), that is no big deal either. Any attacker could look at a "traditional" web application and use built-in browser tools, add-ons, or sniffers like Charles or WireShark to inspect everthing the app sends over the wire. So, if you have a REST API, they can see how to handle all types of data processing - CRUD. They can collect a list of all users, delete users, add data, etc.

In your "what if" scenario of creating 1M users in a few hours, how is that any different than your backend? If there is a signup form, I can programatically fill that form out all day long using browser tools or cUrl and send you submissions. How do you stop that? Don't you want users to signup? Parse is no more vulnerable to this than your backend or Facebook.

Now, comes the important part. As with ANY client server architecture, a good developer NEVER trusts data from the client. First, any serious application will require authentication. I'm sure your LAMP stack or Java or whatever application does this. Guess what? Parse, Kinvey, Backendless, Azure, etc all have authentication available to the developer. The developer decides what type of authentication to use. Then, the developer decides what access controls to put on any collection ( basically "table"). The developer decides if the collection is private, shared, read-only, etc. Next, just as with your LAMP stack, the DEVELOPER is responsible for data validation and security. That developer must ensure on EACH request that the data change is permissible for that user. They must ensure the data meets validation requirements. The developer can have before-save, on-save, and after-save triggers for every CRUD event. This is the exact same thing a developer should be doing on any other client/server architecture.

So, if the developer still has all these responsibilities, what is the point of a Backend As A Service (BaaS) provider like Kinvey, Parse, Azure, etc? Ease of setup is the primary one. I don't have to setup a LAMP stack. I don't have to harden Apache. I don't have to patch PHP bugs. The devloper doesn't need to worry about CDN's and firewalls. The BaaS provides all this "devops" work for the developer. Next, I'd argue that the authentication system provided by these BaaS services is probably more secure than what many developers (myself included) roll on their own. You want Facebook or Gmail authentication - have fun rolling that on your own. Finally, the REST, JavaScript, iOS, or Android API's are light years ahead of the average developers quality. These guys are really good at this stuff.

So, "Is Parse a secure solution?" Yes, it is as secure as the developer makes it. BaaS providers are inherently no less secure than any "you own it" backend architectures.

Anyone else have input on this?
Source: http://www.linkedin.com/groups/Is-Parse-secure-solution-2204708.S.277308762?view=&srchtype=discussedNews&gid=2204708&item=277308762&type=member&trk=eml-anet_dig-b_nd-pst_ttle-hdp&fromEmail=&ut=2hiknrEcaW75Y1