Firebase Security

Preface

Edit: 11/27/2020
I just wanted to add something that I realized shortly after releasing this. You have to enable Anonymous Authentication for your project before someone can use it to hack your project. If you want to enable users to use your application without needing to create an account, enable Anonymous Authentication for your application first.

Welcome to the second installment of using Firebase in Sololearn! This means you must be interested in how to secure your applications and make them safe to use in an environment like Sololearn. When you start giving users of your application the ability to write to your database (this includes creating records and updating records), you have also given malicious users the ability to "hack" your application. This is especially true for web applications and even more true for web applications on Sololearn. Normally, the JavaScript for a web application is served to the user by a web server. For most users, this means the only way to access that code is by using their browser's dev tool console. On Sololearn, the code is in plain sight and is very easy for any person to change before running it.

Before I get into the details of security, check out my first tutorial that goes over the Firebase basics here. For those that aren't familiar with Firebase, you can read about how to add Firebase to a web application here.

One of the problems with Firebase is that it is so easy to use. Yes, you read that correctly; it's a problem, and I will tell you why. Nothing is stopping an inexperienced developer from starting a Firebase project for a webapp that allows its users to write to the database. In fact, it's encouraged. You see tutorials for chat applications all over the internet, and for most of those articles, the author seems to think that security means denying database requests for unauthenticated users. You might be asking, 'Well yeah, that sounds secure. What's the problem with that?'. A hacker that has done their research will know that Firebase offers what's called Anonymous Authentication. All they would need to do is copy your Firebase config JSON and start making calls from their own local web app in which they have anonymously authenticated themselves. Let this be the first lesson - your database is not secure when your only security rule is to check if the request came from an authenticated user.

Security Rules

You are probably wanting to know how to make good security rules, so lets look at some examples of bad rules and improved rules that will make using Firebase databases on Sololearn possible. The first code example below is a perfect example of what not to do. In fact, this was taken from a tutorial I found by Googling 'building a chat app with firebase'. Bad Tutorial

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /books/{book} {
      allow write: if request.auth.uid != null;
      allow read: if request.auth.uid != null;
    }
  }
}

The security for this Firestore database can be vastly improved by only adding a couple of other checks on the type of authentication the request has. View the improved version below.

service cloud.firestore {
  match /databases/{database}/documents {
    match /books/{book} {
      allow write: if request.auth.uid != null && request.auth.token.firebase.sign_in_provider != 'anonymous';
      allow read: if request.auth.uid != null && request.auth.token.firebase.sign_in_provider != 'anonymous';
    }
  }
}

You can even wrap these longer and repetitive rules in their own functions like I've done below. If you want to learn more about the security rule language, you can read about it here.

service cloud.firestore {
  match /databases/{database}/documents {
    match /books/{book} {
    
      function isAuthAndNotAnonymous(auth) {
        return auth != null && auth.uid != null &&
          auth.token.firebase.sign_in_provider != 'anonymous';
      }
      
      allow write: if isAuthAndNotAnonymous(request.auth);
      allow read: if isAuthAndNotAnonymous(request.auth);
    }
  }
}

So now we are only allowing reads and writes for users that are authenticated and are not anonymously authenticated. This elimates the concern I spoke about above, where someone can use your JSON config and make requests as an anonymously authenticated user. However, there is one more authentication method called 'custom'. This allows developers to integrate with their own authetication server that generates signed tokens. The good news is that you don't have to worry about this, because the token must be signed using a private key that is known only by your Firebase project. If you haven't generated one, there won't be custom-authenticated users trying to use your Firebase services. That being said, it won't hurt to include that case in your security rule.

service cloud.firestore {
  match /databases/{database}/documents {
    match /books/{book} {
    
      function isAuthAndNotAnonymous(auth) {
        return auth != null && auth.uid != null &&
          !(auth.token.firebase.sign_in_provider in ['anonymous', 'custom']);
      }
      
      allow write: if isAuthAndNotAnonymous(request.auth);
      allow read: if isAuthAndNotAnonymous(request.auth);
    }
  }
}

Validating Incoming Data

Whenever you allow users to write to your database, like in a chat application, you are also probably using that data to populate the content of your application. Continuing with the chat application example, we know that users are typing into a text field, saving that text to the database, and then populating the web page with that text. All other users in the chat are also receiving the same data, if it's all working like it should. If you are not familiar with Cross-Site-Scripting attacks, take the time now to look it up (A.K.A. XSS attacks). This is where a hacker will type code into the input field instead of text. For example, I could type
<script>document.body.innerHTML = "";</script> into the input field and have the application save it to the database.

Now, when everyone else's view of the chat application receives this new message, the entire application will empty the contents of the page. At this point, the application has been hacked and has ruined the experience for all the other users until the Firebase admin goes into their console and clears the database of that specific message. This is exactly what happened with a popular chat application on Sololearn you may have heard of. So how do we prevent something like this? We will validate the incoming data before saving it to the database, and we can do this with - you guessed it - security rules. The below example is what I would do to prevent this. I also check to make sure the msg field is empty with ^$.

service cloud.firestore {
  match /databases/{database}/documents {
    match /books/{book} {
    
      function isAuthAndNotAnonymous(auth) {
        return auth != null && auth.uid != null &&
          !(auth.token.firebase.sign_in_provider in ['anonymous', 'custom']);
      }
      
      function incomingDataIsValid(data) {
        return !data.msg.lower().matches('^<script>.*$|^<style>.*$|^$');
      }
      
      allow write: if isAuthAndNotAnonymous(request.auth) && incomingDataIsValid(request.resource.data);
      allow read: if isAuthAndNotAnonymous(request.auth);
    }
  }
}

If you are paying attention, you probably noticed that this doesn't stop users from typing other HTML elements into their input field, and you would be correct. I wouldn't want to write a match that contains every HTML element that has ever existed or will exist in the future, and the short answer is that you don't have to. Something that many people do when developing applications like this is use the innerHTML property. DO NOT - I repeat - DO NOT use this property to add content that users have created to your application. This property does some things in the background that many novice developers don't realize. One of those things is the evaluation of code. By using this property, you are allowing code to be interpreted exactly how the browser handles HTML tags, instead of what you intended to do, which is simply add text to an HTML element. For this, you should ALWAYS use the innerText property.

No one can mess with your database now, right? Right?? Not quite. There is one more thing we can do to make sure that our database is safe from people who like to tamper with people's projects. If you are using a paid plan with Firebase, you MUST optimize your database to contain only the information that you absolutely need. Well, "What does this have to do with people tampering with my database?", you may be asking. What would happen if someone were to add fields to the message? For example, let's say our chat messages have 4 fields: timestamp, user id, message, and user name. Due to the nature of NoSQL databases, nothing is stopping you, or other users, from adding another field. Mr. Hacker might add a field called, hahaGoodLuckPayingForThis to the message. They can now fill it with as much data as they want, like the entire lorem ipsum text, and you will have to pay for it. Or worse yet, if you are using the free tier, they've now prevented any further data from being added to the database, which means no one else will be able to send chat messages.

The code down below does a couple of things to prevent this. First, we can check to see that the message only has the number of fields that we would expect. Second, we validate that the number of fields that are present are the ones we would expect. Third, we limit the number of characters that the message can contain. Ideally, we would validate that ALL fields are formatted correctly and have the correct number of characters, and I encourage you to do so. To save space and time, I won't be doing that in this tutorial.

service cloud.firestore {
  match /databases/{database}/documents {
    match /books/{book} {
    
      function isAuthAndNotAnonymous(auth) {
        return auth != null && auth.uid != null &&
          !(auth.token.firebase.sign_in_provider in ['anonymous', 'custom']);
      }
      
      function incomingDataIsValid(data) {
        return !data.msg.lower().matches('^<script>.*$|^<style>.*$|^$');
      }
      
      function dataHasCorrectFields(data) {
        let dataKeys = data.keys();
        return data.size() == 4
          && dataKeys.hasOnly(['timestamp', 'uid', 'userName', 'msg'])
          && data.msg.size() < 240;
      }
      
      allow write: if isAuthAndNotAnonymous(request.auth) && incomingDataIsValid(request.resource.data) && dataHasCorrectFields(request.resource.data);
      allow read: if isAuthAndNotAnonymous(request.auth);
    }
  }
}

The check on the data only having 4 keys is redundant here, but it gets my point across about how to confirm that incoming data is exactly what you want.

Now I would say that your application and database are quite secure. However, this requires you to develop a login flow, where users are required to enter an email address and password. This may deter users from using your application on Sololearn, and you don't want that. In my opinion, I think it's best that you require users to sign in, but I also think that at this point, the security rules cover any malicious intent that a user - authenticated or anonymous - might have. Something that I've done in my personal projects is to take this a step further; I will require users to create an account with an email and password AND verify their account through the validation flow that Firebase Auth has. This flow sends an email to the account and requires the user to click a link to verify that they did in fact use a real email address when creating an account. In my security rules, I check that the user has done this before they can access the database.

Footnotes

Thank you for reading this article! I hope that users of Sololearn who want to get into building real-life applications with Firebase find this useful. If you intend on becoming a freelancer or full-stack developer, learning about security is absolutely necessary. I want to close out by mentioning a couple more things. One other way you can make your database calls secure is through the use of Firebase Functions and the Admin SDK. Functions are pieces of code that run server-side, and you can call them like an HTTP REST endpoint. This allows you to completely control how the data is read from and written to your databases. All the user sees in the JavaScript is that a call is being made to a Firebase Function. The downside to this is that you are required to use the paid plan to use Functions, and one of the metrics that Google uses in their calculation of payment is CPU time. Because you are making asynchronous calls to your database in the Function, the CPU time will go up. This also adds some additional time that the user sees in the end product, which makes your application seem less responsive. However, it makes it so much more secure.

The other thing I want to mention is to READ THE DOCUMENTATION. Whatever framework or library you use in your web applications, please take the time to read through that product's documentation. For example, here is the documentation on security rules. Go read it! You find so many things that become useful to security or functionality by reading through the documentation. Tutorials don't tell you everything and they never will. Even this tutorial didn't cover everything that security rules are capable of; that's what documentation is for!

Finally, TEST, TEST, TEST. Then test some more! Firebase Security Rules has a built-in emulator that you can use to make fake requests to your database. Use this to pretend like you are a hacker and try to come up with ways that a hacker may use to mess up your data or read something they shouldn't have access to.

If you are a hacker or pen tester, please poke holes in my security rules and comment how you would go about penetrating a project like this in the comment section. This is supposed to be a learning experience for everyone. As always, Happy Coding!

Security With Firebase