React, Redux & Firebase App Tutorial #32 - Firestore Security Rules

Key Takeaways

solar my friends I could spend an entire series on security rules and in fact I do plan on doing a mini-series on this in the future but for now in this series I'd like to keep this tutorial fairly focused and simple to give you an overview to them and I will leave a link in the description to an article for more information about security rules if you want to check that out also so anyway what are firestore security rules well basically they are a way for us to lock down our data so that not just anyone could read or write to our database because right now our rules are in a very relaxed test mode which means that anyone with access to our project details on firebase could potentially access data in our database and also manipulate it all they would need is our database endpoints or our configuration information for this firebase project much like we set up in our firebase config file for the react application now that's a security issue which we need to address so that not just anybody can edit the data in our database so it's a view our security rules you want to go over to this tab over here and these things right here these are the security rules currently setup for our database now the way that we write security rules is by matching certain paths in our database and declaring rules for these paths for example we may have a different set of security rules for our project collection than we do for our users collection so we can create rules too much both of those paths independently if we want to okay now the top line right here service cloud dot firestorm that top line scopes these rules for the firestore database only now the second line right here that says that the rules should match any firestore database in our project now we only have one database so we can leave these top two lines as they are we don't need to change them one bit now the third line right here that is saying much any documents in the database and the rules that are set up for this path right here and that is basically saying allow anyone to read or write so for any document inside our database we're saying we're allowing them read or write access so that is what is making these rules really relaxed and this is good for development when we want to test but if we go into production we definitely want to lock down our security a bit more so that not just anyone can read or write to every single document now a fairly recent tool that Google have added to this is the simulator over here so we can simulate requests to different paths inside our database to see who could get access to it and who could edit the data so for example we're seeing right here we want to simulate a get request just to get some data and at the minute say we want to go to the project's collection and in there just to a certain document so this is the ID of one of our documents now if we were to run this right here at the bottom and by the way and not authenticate see right here and this means that I would not be an authenticated user inside the application we've not logged in if I run this then it's going to say that we are allowed access to the data so that means that anyone can go out and grab that data now if we were to make some other kind of request to update the data same again run this or allowed to do that even though we're not logged in and again delete run this and we're allowed to do that now this would be exactly the same for the users collection anyone could go in there and read users information or edit it and this is all because of the current security rules allowing read and write access to every single document so let's update those now so that not just anyone can access or write these documents so then first of all I want to get rid of this thing right here I don't just want to match every document I want to match our different collections differently so we can write different security rules for each different collection so first of all I want to match the project's collection then forward slash the single project so these curly braces right here these just mean we're matching a single project inside the projects collection ok this is variable it represents the single document now that how do we want to set up the security rules well I would like anyone who is signed in and authenticated inside our application to be able to read and write projects okay so allow read and write but it's only if they're authenticated so let's do a colon instead there and this means we're going to specify in a condition and that condition is going to be if then the request we get access to the request object dot off so the authentication status of the user then dot UID so if we have this and it's not equal to null then we're allowing read and write access otherwise we're not okay so for example now if I go to try and delete this and I'm not authenticated if we run this now then we should get an error so we can't do that however if I am authenticated and run this then it should give us access okay so that sorts up the rule for our projects now it's as simple to begin with and you might write more robust security rules if you're doing a larger application with more data that's your choice like I said I'm keeping this simple so the second one now let's match our users path so forward slash users then forward slash the individual user ID okay so that is the document that we have remember inside our database we store each user ID as the document key so inside here now what I'd like to do is allow create so anyone can create a new user ID anyone can sign up right they don't need to be authenticated to begin with to do that anyone can do now now the second rule I'd like to do and we can add multiple rules is allow read to anyone who's logged in so we allow that if and then it's going to be request to all that UID is not equal to nope so anyone who's logged in can read the data of other members as well because remember on the front end we display that data of other members their name is right here so we need to be able to read that if we're logged in okay so finally I liked people who are logged in to edit their own details so we'll say allow right and then that's going to be if request dots or don't you ID and then that's going to be equal to the user ID right here because that represents the user ID inside the database remember if we take a look inside this database if we open it up in a new window then we're going to see the ID of the user if we go into the users collection right here so that is what this represents and we're saying well if that is equal to the UID of the person who's logged in then we allow them to write to their own accounts if you like their own document so if they wanted to change their name at some point they could do we don't have that functionality on the front end of the application but just showing you how you would do this so then now if we go to users like so and I'm gonna say we're not authenticated to begin with and then if we go to create then we should be allowed to do this because we're allowing anyone to create a new account so run this and we get access if we change this to get and we should get an error and we get an error so we can't do this if we change this to update and try to run then we get an error and if we change this to be authenticated and we try to get and run this we should be allowed access because anyone authenticated can get read access let's see if we can write to this over here so we'll say update and press run and we get an error we can't do this because the user ID must equal to the UID of the person who's logged in now we can specify that down here so what I'm going to do is grab this which is the document ID we're trying to edit and I'm going to set that to be equal to the firebase UID of the user who's logged in then we should get right access so press run again and now it works so let's publish these and then let's just then preview on the front end now it may take a few minutes so I'm just going to pause here then I'll test it out in a second and see you on the other side all right then so now we've published those new security rules let's just make sure the application still works and we can do everything so currently logged in as Mario and I can still read all the data so all that is still working now if I try to add a new project I should still be able to do this because I am authenticated and we said authenticated users can create new projects so so I taught collect or the gold stars and then whatever for the content let's try creating this ok so that's working we can see that project at the bottom so everything is working with the project's collection now if I try to log out what I'd like to do is sign up so we said that anyone can create a new record in the users collection so let's try adding peach at the net ninja quarry at UK and then the password is test one two three four first name is peach and the second name is whatever and then signup and this should work yep okay so we're now authenticated and we can read all of the data like so so this is all still working and now we've locked down our data using the firestore rules over here so that only authenticated users can read or write projects anyone can create a new user anyone whose offense cated can read user data but only people who are authenticated can write to their own document so that's fire store rules in a nutshell again this was very much the basics so if you want to read more about them I'm gonna leave a link to the documentation there's a lot of information about how to do many different things inside the rules if you want to check that out as well