Securing your Firebase app (part 2)

This is the second article in the series of “Securing your Firebase app” and we’ll look at security in the form of “accountability” and to establish a relationship of trust between your data and the clients.

Anonymous Authentication

The anonymous Authentication is a great way to certify that you’re talking to the same client throughout a session and/or in between several visits to your site.

This is not the same thing as talking about HTTPS and preventing a man-in-the-middle attack. This is more concerning accountability and traceability. Knowing that we’re talking to one and the same client, we can implement security rules that are starting to look like real user account authentication rules.

I’d even go so far as to say that there are few reasons to not already start off by signing in your client with an anonymous account from the beginning. It is a completely transparent action that does not require any user interaction.

One of the benefits of this practice is that you can associate certain data to your client throughout the lifetime of the anonymous account.

Once your user/visitor has gone reached the stage where you want to bind her more permanently to your system, you can merge the anonymous account to a “real” profile account.

The account will be stored in a similar fashion as cookies and any web client that is returning to your site or web application will keep its anonymous account until explicitly clearing the local data for the site. The account is bound to the browser session, which means that signing in to another Chrome account, for example, will also mean another account.

So even without having your user/visitor creating an account, you can still enforce security rules applied to the person that you most certainly know is the same one throughout the session.

For example, consider the trivial example of an anonymous blog commenting system where anyone can leave a comment, but only the original author can edit or delete her own comments.

The next step is of course to implement real account sign-in, since it will give the best user experience and accountability. The anonymous accounts are limited to the browser in which they were first created. Not a very good experience since it won’t allow us to check back in from another device or browser.

Web clients

Even though you have accountability, you don’t get sanity or prevention of unexpected client behaviors.

Due to the nature of web clients, your code will be completely open and accessible to your users. I am not saying “readable” because you can always add a layer of protection by minifying your JavaScript code. But that’s security by obscurity, and although it’s good practice, it’s not truly a security measurement.

There is little you can do to prevent a client from pausing your script in the developer tools of the browser to modify values or doing something unpredictable.

But apart from having a healthy amount of paranoia, you should be concerned with consistency and reliability of the data that clients are saving.

And of course, since I am leading the argument in that direction, there is a way of solving that.


Yes, you heard me: backend! Or, more like a trusted client with elevated privileges. Let’s call it a friend with benefits.

You can easily add an additional layer of control to the data that is being stored in your application’s database by setting up a lightweight NodeJS worker on your favorite server hosting.

Create a service account for your NodeJS server and set it to monitor all paths in your database where you think that some supervision might be needed.

The NodeJS worker can help you to sanitize messages, fan out data for denormalization or help to process tasks in the background, such as calling out to a third party’s API based on the state of data in your system.

In the following article, I will cover Firebase queues; a library that is implementing advanced techniques for task processing and using the Firebase database as a message bus.

Stay tuned…