Break Up Firebase Security Rules Into Different Actions Depending on Operation Performed
Currently our Firebase Security Rules aren't as secure as they could be. When it comes to tasks, we are comparing the request's user on the task to the requests auth id. If someone intercepted this request and changed the ids here they could get away with it.
In this lesson, we'll go through our security rules and create a different set of security rules depending on the action the user is performing. For tasks specifically we will check the documents user id against the request user id.
We'll take things a step further as well and write different rules if a user is trying to create, delete, or update a task document.
Man 1: [0:00] We can take our security rules to the next level by adding a little bit more security. Here's the thing, what happens if someone intercepts the request and spoofs the auth object and changes the user ID?
[0:16] Since this is going to check that the user ID in the request is the same user ID as the user ID in the data that's coming, I can change the data that's coming. I can intercept it, change it, and send my user ID here.
[0:33] That way, I can access that document. To prevent this, Firebase has two ways where you can access the data. One is from the request itself and the other one is from the resource.
[0:46] When I say resource.data.user, it's not going to check the task that's coming in the request. It's going to get that user ID and it's going to check the task object that we have in the database.
[1:02] It's going to check that in the database we have a task with this ID and that task has this user property and that user property is the same as the authentication ID that the currently user is sending. This is more secure because if the user intercepts the request and tries to change the user, they can send whatever ID here they want, but our check is not happening against the request data.
[1:33] It's happening against what we already have in the database. Then we run into a new issue. When we are talking about reading data, if I am fetching a task or if I am trying to get the entire list of tasks, it's OK to check against the resource because the tasks are there in the database.
[1:56] Let's say that I am creating a task. If I am creating a task, there is actually no task in the database. This resource here is [inaudible] because there is nothing to check against. For that specific case, we want to check the data in the request.
[2:14] For that, what we can do is that we can separate our security rules depending on the operation that is being performed. Firebase allows us to do this to check depending what the user is trying to do. We can say allow read and we can say allow write.
[2:35] Since write is divided in multiple operations like create, update or delete, it's a better idea to do one line for each because both update and delete are going to require different set of permissions than create.
[2:56] Now here we can say when I'm going to read the data, the resource in the database exists, so we are going to check against the resource. When I'm going to create the data, there is no resource in the database, so I'm going to check this against the request.
[3:12] When I'm going to update or delete a task, I need to check against the resource because that task exists there in the database.