How to implement firebase server side security

Question

I'm currently working on a new google polymer web application and wondered if I should use firebase as the backend/db. I took a look at the project, made some test applications and really liked it! But to fully convince me, that firebase is the way to go I need the following questions answered:

1. I'm a little bit concerned about security: So, I know, that firebase uses read, write and validate to implement server side security. From the samples, I noticed that the validation basically is a one-line JS script, that represents a 'if'. As I'm planning to build a web e-commerce application I need to validate quite some inputs. Is there a possibility, to outsource the validation in a separate file, to make it more readable? Also I wondered, if there is a possibility, to test these server side validations, with for example unit tests?

2. I'm not 100% sure at the moment, that firebase can cover all of our use cases. Would it be possible/a good solution to use a "normal" backend for some critical functions and then persist the data from the backend in firebase?

3. I saw some nice polymer elements for firebase. Is firebase 100% supported in polymer/web components?

4. Is there an other way (like Java approach) to implement server business logic?

5. Is there a way, to define update scripts, so that new releases can easily be pushed to production?

Thanks & kind regards

Marc

Answer 1

So, I asked the firebase supprt and got the following answer:

Great to meet you.

1. I'm a little bit concerned about security: So, I know, that firebase uses read, write and validate to implement server side security. From the samples, I noticed that the validation basically is a one-line JS script, that represents a 'if'. As I'm planning to build a web e-commerce application I need to validate quite some inputs. Is there a possibility, to outsource the validation in a separate file, to make it more readable? Also I wondered, if there is a possibility, to test these server side validations, with for example unit tests?

You can implement extremely complex and effective rules using our security rules language. You can deploy security rules as part of your hosting deploy process, or via the REST API. It's not possible to break the contents into multiple files on the server, but you could certainly build your own process for merging multiple files into a single JSON result.

2. I'm not 100% sure at the moment, that firebase can cover all of our use cases. Would it be possible/a good solution to use a "normal" backend for some critical functions and then persist the data from the backend in firebase?

Generally speaking, synchronizing Firebase and a SQL back end is not very practical and they don't translate well. It's probably entirely redundant as well.

3. I saw some nice polymer elements for firebase. Is firebase 100% supported in polymer/web components?

I don't know what 100% supported means in this context. We offer a JavaScript SDK so they should play fine together.

4. Is there an other way (like Java approach) to implement server business logic?

We offer official SDKs in Java, Objective-C/Swift, Android, Node.js, JavaScript, and a REST API for use with other languages.

5. Is there a way, to define update scripts, so that new releases can easily be pushed to production?

I'm not sure what this means. Most likely the answer is no, since we don't provide a build process or any tools to release your software.

I hope that helps!

I responded:

Thank you for the information, it helped me very much! After reading your response on question number 5 one further question popped into my mind: … 5. Is there a way, to define update scripts, so that new releases can easily be pushed to production? I'm not sure what this means. Most likely the answer is no, since we don't provide a build process or any tools to release your software.

Is there like a best practice on how to handle the database schema? I only have one web application (without apps, etc.) in my case... I expect, that the database will change drastically over time and releases. Should I write JS logic, that checks the current database version and update it, if it's necessary? Maybe this would make a nice feature...

For example: I deployed Version 1.0 of my application and everything works fine. After 3 months of programming I notice, that the user data needs a further attribute: address, which is a 'not null' attribute. I now deploy Version 2.0 of my application and every new registered user has a address, but the old users (from Version 1.0) do not have this field or a value.

How should I handle this?

Support responded:

Hi Marc,

There’s no best practice here, but your ideas seem fairly sound. You probably don’t need to check in your JavaScript. You can probably store a version number in the user’s profiles, and when they upgrade to the latest software, you can upgrade that in their profile data.

Then your validation rules could use something like the following:

{
   "user": {
       ".write": "newData.hasChild('address') || newData.child('appVersion') < 4",
       "address": {
            ".validate": "newData.isString() && newData.val().length < 1000"
       }
   }
}

So if you are concerned about versioning, this could be used to deal with legacy releases.

Another popular approach I’ve seen from devs is to do intermediate upgrades by duplicating data. Thus, you release an intermediate version that writes to the old path and to the new path with the updated data structure (which keeps the app working for old users till they upgrade). Once a reasonable percent of clients are upgraded, then release a final version that no longer does a dual write to the old structure and newer structure.

Of course, flattening data, while it makes joining and fetching data bit more of a pain, will make upgrades much easier as the modular data structure adapts more easily to changes. And, naturally, a pragmatic design where you wrap the various records in a class (e.g. the UserProfile class with getter/setter methods) makes transitions simpler as you can easily hack in versioning at one place.

Hope this helps someone :)