Firestore Security Rules - How to Hack a Firebase App

Key Takeaways

I can hack into your firebase app in about 10 seconds then steal and delete all your data assuming you fail to set up back-end security rules allow me to show you all I have to do is pull up an app and go into the chrome developer tools under the network tab then find a request coming from firebase open up the headers and find the corresponding project ID from there I can just go to the command line and run a curl delete request to the firebase REST API and start wiping out this app's database if you deploy a firebase app without backend rules anybody can do this to your app as well today I'm going to show you how to keep your firestore database secure by writing expressive easy-to-understand back-end security rules if you're new here like and subscribe and grab the source code from angular firebase comm to get started you'll want to go to the firestore database and then open up the rules tab rules are defined in their own special language that somewhat resembles JavaScript currently the arrows pointing to the root of our database and all of our rules logic will be defined inside this block then we use the match keyword to point two paths in our database where we want to apply rules in this case we're using that equals star star to match every single document in the database then we use the allow keyword followed by the operation that we want to set a rule for in this case reader right if we leave it blank it's going to allow those operations or we can write an expression that returns true or false to apply some actual rule logic to this route for example if we wanted to completely lock down all documents we could say if false and then nobody could read or write from the client-side if I try to query a collection from my front-end app I'm going to get an error in the browser console so cool now our apps 100% secure but that's a little too secure now we're going to write some rules that perform logic based on user authentication the underlying data the incoming request time etc first let's look at the various types of requests that we can lock down first we have get which would apply to reading a specific document then list would apply to a collection query so those are our read rules then our write rules we have create which applies to creating new data update for modifying existing data and delete for removing data in addition we could say allow read which would just combine getting lists or we could also say allow right which would can buy and create update delete into a single rule so that's how we scoped rules to specific operations now I want to show you how to point to the actual data that we want to apply these rules to the first thing to make note of is the equal star star that special syntax is going to tell your rules to cascade down to all sub collections and anything nested under that path that's useful when you have a rule that's applied to many different collections such as verifying a user is authenticated you can also make your rules very specific for example we can point to a specific document using that document ID all you have to do is hard code it directly into the path and then write the corresponding rules that can be useful sometimes but the single most useful matcher is the wild-card ID instead of hard-coding the ID we just add brackets with a variable name that we can evaluate as the ID at runtime by setting product ID right here we can use that as a variable that represents the document ID then we can evaluate that ID in the actual allow statement which will see an action here throughout the lesson and the wild-card is by far the most common matcher that you're going to be using throughout your back-end rules I'd also like to point out that your rules are secure by default so unless you explicitly allow an operation it's going to be blocked by firestore and my demo here I'm allowing the user to read the documents but only delete a document if they are logged in we can figure that out by looking at the request object that is built into the rules environment the request object is very important and for one it gives us information about the current user to simply see if the users logged in we can see if the request off does not equal null so that's pretty cool but the thing I don't like about it is that it doesn't read very well that brings me to my favorite part of firestore rules and that's the ability to write your own custom functions functions allow us to repurpose our rules in a way that's dry and readable so instead of writing if request auth does not equal null a whole bunch of times I'm going to write a function called is signed in the function will just return the request auth does not a null statement then we can replace it on the allow line and now it just reads like a plain English sentence that anybody can understand allow delete if signed in pretty simple my goal from here on out is to give you a bunch of helper functions that you can easily reuse in your own project the next thing we might want to do is determine whether or not a user is the owner of a certain document a good example might be a user profile where all users can read other users profiles but only the owner can write to it so here we're matching the users user ID document and allowing read if they're signed in but only allowing write if they're the owner user and notice how we're passing the wild card variable to the argument in our function for this to work it's important that the document ID matches the user ID and if you've seen my authentication tutorials you'll know how to do that then when defining this function all we have to do is look at the auth user ID on the request and compare it to the user ID on that document that we passed as the argument if the IDS are the same then we know that the current user is the owner of this document and we can actually get a lot more sophisticated let's say we want to determine whether or not a user has a verified email I'm going to use an and statement to chain another function to our rule with an and statement both functions will need to return true for this rule to pass you can also change things together with an or statement to check if only one of the conditions is true but in this case we want to make sure that users the owner and that they have a verified email like I mentioned before the request object has all kinds of useful information in this case we're going to look at the token on the auth object that contains an email verified property of true or false we can also see when a user signed up if they're anonymous if they have a phone number to compose all kinds of other useful rules but another common thing you'll need in your rules is to know what the existing data looks like as compared to the incoming data to get the existing data you can use the resource keyword followed by data but try not to confuse that with request resource data I recommend writing functions as existing data and incoming data just to make this very explicit and clear because these are easy to mix up and it's really important that you don't mess up your back-end rules so when might you need existing data a common use case would be if you have a certain document that maybe gets locked after it's published if we jump up to the products path we can look at the existing product document and we'll make sure that it's not locked before running the update checking existing data is usually most important when your users can control whether or not a document should be modified at some point when it comes to incoming data there's all kinds of validation rules that we can apply to our underlying data structure let's imagine that our product document of greater than $10 so if the user tries to send an update where the price is less than $10 we're going to cause this update to fail so looking at the incoming data is very important for maintaining the integrity of your database now switching gears in episode 75 I talked about rule-based user authorization and I want to revisit some of those concepts now in that lesson we saved information about the user's role on their user document and we need to read that document when applying a rule to various parts of the database this documents not going to be available on the user object so we're going to need a different mechanism to read the document whenever needed the rules environment has a get keyword that will read a document by pointing to a specific path we need to use the absolute path so this gets pretty verbose but if you put it into a function then it's not too bad we write out the path like normal and then use dollar sign parentheses and interpolate the request auth user ID this gives us the current users document and firestore which contains information about their authorized roles now let's use this function to authorize a user to update a product we can read the document and then we have an object of roles so we can get all of the keys from that object by calling keys on it then has any will check if the user has any of these authorized roles such as editor or admin you can also use has all to make sure that the user has all of these roles at the end of the day that gives you a very simple solution for implementing rule-based user authorization another interesting thing to think about is how time impacts your database security a common scenario is to throttle the amount of data that a user can create during a certain duration of time we can get the current time of any request by just calling request time then there's a duration helper that we can use to operate on the time stamp for example we want to make sure the request time comes after the created at time stamp plus a duration of 60 seconds in other words the user can only write to a product document every 60 seconds so duration just allows you to add a number of seconds minutes or hours and compare them to a firestore timestamp I'm going to go ahead and wrap up there hopefully this helps you avoid becoming the next major data breach victim if this video helped you please like and subscribe and if you're ready to take things to the next level consider becoming a pro subscriber at angular firebase calm you'll get a whole bunch of exclusive content and direct access to chat with me on slack thanks for watching and I'll see you soon