Firebase engineer here: BaaS (and "serverless" in general) mean that since you don't control your database/storage/servers/etc. you no longer have the ability

Firebase engineer here: BaaS (and "serverless" in general) mean that since you don't control your database/storage/servers/etc. you no longer have the ability to implement your own custom Authentication and Authorization. Firebase solves this by using Firebase Authentication (https://firebase.google.com/docs/auth/ https://firebase.google.com/docs/auth/) to determine who a user is and Firebase Rules (currently implemented in the Realtime Database [https://firebase.google.com/docs/database/security https://firebase.google.com/docs/database/security], which this article mentions, and Firebase Storage [https://firebase.google.com/docs/storage/security] https://firebase.google.com/docs/storage/security]) to determine what a user can do. Yes, they're different languages, and we're working on upgrading the Realtime Database to use the new language syntax (we know it's a pain point, and we plan to address it). I strongly recommend watching our I/O talk on "The Key to Firebase Security" (https://www.youtube.com/watch?v=xAsvwy1-oxE https://www.youtube.com/watch?v=xAsvwy1-oxE) which walks through the basics as well as shows the power of our rules system. While you probably can't specify all of your business logic in our Rules languages, you can enforce a vast majority of cases (including building things like per user rate limiting: http://jsfiddle.net/firebase/VBmA5/ http://jsfiddle.net/firebase/VBmA5/ and secure client side only trades: http://jsfiddle.net/firebase/j562wj1r/ http://jsfiddle.net/firebase/j562wj1r/). FWIW, this system is not a concept unique to Firebase. Parse has user ACLs (PFACL, PFRole on iOS for instance: https://parseplatform.github.io/docs/ios/guide/#roles https://parseplatform.github.io/docs/ios/guide/#roles), and Horizon has it's own Rules templating system ( http://horizon.io/docs/permissions/ http://horizon.io/docs/permissions/).