Secure your Firestore Data with Security Rules
All the security we've added to our application has been client side. In a production app this isn't enough, we want to add security to our database directly.
We'll start securing our application's database with Firestore Security Rules.
We'll write security rules to prevent unauthenticated users from accessing our database, and then we'll add extra rules so that only a document's owner can access that document.
Instructor: [0:00] So far, all of the security we've added to our application has been client-side. We also need a way to secure our database. For that, Firestore provides us with expressive query language that's called Firestore Security Rules.
[0:15] Here we can start securing our database. It starts us off with a single rule that is a wildcard. It says everything that matches in our database and it's going to have to allow read or allow write if the request timestamp is less than amount from now because that's how Firestore starts in development mode.
[0:41] It's going to just let you write and read everything from the database because we are working on development mode. In the past, this was like this. Basically, the whole database was always open but people started forgetting and they would deploy their applications with the open Security Rules so that's why they changed it to have like a specific date.
[1:05] That way in 30 days your database stops working and you have to manually go there and say, "Oh, I need to change my Security Rules." We're going to add two rules right now. First is that we want only authenticated users can see the data in our database. For that, we can come here and we can say allow read and write if the request.of is different from.
[1:38] This is going to say, "OK, we are going to allow you to read or to write anywhere in the application if you are an unauthenticated user." For the second one, we need to make a change here. If we go back into our application, we see that we have two collections -- users and tasks.
[1:58] Instead of having this wildcard here that catches everything, we are going to create one set of rules for the user collection. This says, "Anything that matches users/user ID when I wrap it in curly braces, it's a variable." It's going to run this rule, so allow read or write if the user is authenticated.
[2:24] Then we're going to do the same for our tasks. For the tasks, we want to say, "I don't want authenticated users to see all of the tasks. I want the tasks to be available only for the users that created them."
[2:43] We can change rules here and we can say if the request is different from the request authentication is there like it's different from null and we can also say if the request.data.user, it's the same as the request.of.userID.
[3:07] What this does is that it's going to check. This is the user ID of the currently logged-in user. It's going to evaluate the request that's happening against the database. In the request, it's going to check for the authentication object. From there, it's going to get the user ID and it will check, "OK, is that request the same as the variable user inside of the data that I'm getting?"
[3:36] It's going to check if the task.user is the same after the user that's logged in and then it's going to let you do this. We can do the same up here. We can check, is the request.of.uid the same as this user ID? Remember that this is a variable so we can check for it here.
[4:03] It's the document that I'm trying to access, that document has the same ID as my user ID because that's my user profile. I should be able to access it. This way, both collections are blocked and only the user that created document is able to see or to interact with that data.