I know that Firebase has the FieldValue class, which can be used to generate e.g. a server-side timestamp when writing a document (link).
What's the preferred practice for inserting the current user's uid into a document?
Having the client provide that field seems to allow misuse - unless I provide a server rule that checks for (new/updated) documents to match the request.auth.uid, something like:
service cloud.firestore {
match /databases/{database}/documents {
match /broadcasts/{broadcast}/chatMessagesCollection/{message} {
allow write: if request.resource.data.uid == request.auth.uid;
allow read: if true;
}
}
}
I can't find anything on the web for the use-case of having a document be populated with the user writing it -- so what's the best take on this?
What you're doing now with security rules to enforce that the provided UID matches the current user is exactly the right thing to do. There is really nothing better (for this specific use case), and this is a common practice.
I've even written about it in this blog series: https://medium.com/firebase-developers/patterns-for-security-with-firebase-per-user-permissions-for-cloud-firestore-be67ee8edc4a
Related
I created a website for a theatre company with a list of their upcoming shows.
Thes dates are stored in firestore, so I put up some rules:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read: if true;
}
match /{document=**} {
allow write: if request.auth != null;
}
}
}
I just want the admin to be able to write when they are logged in, but I want everybody to be able to access the database to read the dates.
I thaught it was ok, but I get a new email every day from firebase saying that the database is not secure because anybody can read my data.
What should I do?
Your security rules should allow exactly what your code requires and nothing more. This is known as the principle of least privilege, and is the best way to ensure malicious users can do no more than your own code already does.
Let's look at making reads and writes more secure in turn.
Securing reads
Your rules currently allow anyone to read the entire database. But your code doesn't read the entire database. It instead only reads a list of upcoming shows. So you should only allow reading of upcoming shows:
match /databases/{database}/documents {
match /upcoming_shows/{document} {
allow read: if true;
}
So now users can only read from a single collection: the one named upcoming_shows.
If you actually have a list of all shows, and your code only reads the upcoming shows by using a query, you could also secure that query so that someone reading all shows gets rejected.
As said at the start: your rules should only allow exactly what your code requires, and nothing more.
Securing writes
You said that only the administrator should be allowed to write data when they are logged in. But right now anybody who signs in to Firebase Authentication can write whatever they want in your entire database. So a malicious user can take the configuration from your application, call Firebase with that to sign in, and then for example delete all your data, add their own fake shows to it, or just create an entirely different data set in the database, that you then pay for.
There are two parts that you'll want to better secure:
Only the administrator can write.
They can only add shows.
Only the administrator can write
You know the administrator it seems, so you can probably find their UID in the Firebase console and simply hard-code that in your rules:
allow write: if request.auth == "uid of your known administrator";
Now with these rules, since Firebase determines the UID of the user and it can't be spoofed, you've ensured that only the one person that you identified can write to the database.
There are many variations of this pattern, but this is a good first step.
They can only add shows
With the above changes we already ensured that only the administrator can write, but they can still write whatever they want. The principle of least privilege dictates that we should ensure they can also only write what they must be able to write. In your case that is "adding new shows".
This again breaks down into two requirements:
The administrator can only write shows, meaning they can't write other types of data, or write data elsewhere in the database.
The administrator can only add shows, meaning they can't update or delete them.
Only allow writing of shows
The first requirement is two-fold once more, the first one being similar to what we did for reads: we want to ensure they can only write to the upcoming_shows collection:
match /upcoming_shows/{document} {
allow write: if request.auth == "uid of your known administrator";
}
The second part is that they can only write shows there, meaning you'll want to validate the data that they write. You'll want to only allow the fields that your code actually writes as (again) the rules should only allow exactly what the code does, and nothing more. This could include validating that the date of the show is in the future, if that is also something that your use-case requires.
Only allow adding shows, not updating/deleting them
Then finally your use-case says they can only add shows, which I read as not updating and/or deleting them. We can use granular rules to implement that requirement:
match /upcoming_shows/{document} {
allow create: if request.auth == "uid of your known administrator" &&
/* the validation rules from the previous step */;
}
When submitting data, I want to ensure that my client cannot persist random fields.
Meanwhile, I want to keep my app the simplest as possible and I am trying to do it using only firestore rules and/or indexes (i.e. not using some server side express). Is it possible?
I know how to check the existence and the type of a field :
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /example/{exampleId} {
allow create: if "fieldOK" in request.resource.data &&
request.resource.data.fieldOK is string
}
}
}
But I do not know how to block the creation of a random field such as "fieldBS" when you cannot do a loop in your rules.
Yes, you can ensure that an object has only a certain range of keys using hasAll or hasOnly.
request.resource.data.keys().hasAll(['admin']);
request.resource.data.keys().hasOnly(['admin']);
You can use this at arbitrary levels of nesting on Map (key/value pair) style data.
The Firebase Rules Reference is a great resource for questions like this.
After checking only the supported range of keys are present, it's still important to sanity check each individual field thereafter.
I've got a Firestore collection.
The IDs of the documents are secrets. You should be able to read only the document whose ID you know.
For the sake of simplicity. I'd like to stick to this approach.
However, by default, one can read an entire collection from Firestore, for example
await firestore.collection("secret_documents").get()
Is it possible to allow reading only one document at once, only when it's referred by its ID?
Yes, that is actually quite easy. To control what documents can be accessed, use Firebase security rules for Firestore.
By default your security rules will be read and write, but those can actually be broken down into more granular operations of get, list, create and update. And what you're trying to do is to allow get, but not a list operation. From the documentation:
service cloud.firestore {
match /databases/{database}/documents {
// A read rule can be divided into get and list rules
match /cities/{city} {
// Applies to single document read requests
allow get: if <condition>;
// Applies to queries and collection read requests
allow list: if <condition>;
}
...
So to allow get for everyone and disallow list calls:
allow get: if true;
allow list: if false;
You'll probably want to elaborate on the allow get rule a bit, because it's more common to restrict it, for example to users that are signed in to your project with Firebase Authentication:
allow get: if request.auth.uid != null;
https://firebase.google.com/docs/firestore/security/rules-query
The Firestore documentation shows examples of how to secure data using Firestore security rules based on the request.auth.uid field. These typically look something like this:
service cloud.firestore {
match /databases/{database}/documents {
match /stories/{storyid} {
// Only the authenticated user who authored the document can read or write
allow read, write: if request.auth.uid == resource.data.author;
}
}
}
That makes perfect sense.
What I don't understand (and doesn't appear to be shown anywhere) is how to set the resource.data.author field securely.
Obviously that can't just be based from the client because then any authenticated user can tamper with the request to set their author to any value.
I thought maybe we are supposed to use CloudFunctions to set that field but at the moment this doesn't work.
The impact of this is pretty clear in the role based access example:
{
user: "alice",
content: "I think this is a great story!"
}
Surely there must be a tamper-proof way to set the user field there - otherwise any user can make their comments appear to be from anyone else. This seems bad.
In the Firestore example web app, it seems to set the userId field on the client side and I think it is doing the same in the Android version.
What am I missing?
Edit: as #imjared points out this rule implies that 'alice' in user: "alice" is actually a uid, so I think this is safe.
I knew I was missing something.
match /comments/{comment} {
allow read: if isOneOfRoles(get(/databases/$(database)/documents/stories/$(story)),
['owner', 'writer', 'commenter', 'reader']);
allow create: if isOneOfRoles(get(/databases/$(database)/documents/stories/$(story)),
['owner', 'writer', 'commenter'])
&& request.resource.data.user == request.auth.uid;
When the user writes a document to Firebase, they can indeed send any value for the author field they want. But there's no way for them to set request.auth.uid. This last bit in crucial to ensure all (read and write) access is authorized.
The first rules snippet you shared actually has two rules, and it might be easier to separate them out for a moment:
allow read: if request.auth.uid == resource.data.author;
allow write: if request.auth.uid == resource.data.author;
The write rule only allows the operation when the author specific in the request is the same as the request.auth.uid. Since request.auth.uid can't be spoofed, and the value of author will only be accepted if it is the same, the write operation is only allowed if the author field is that of the currently authenticated user.
In fact, that latter rule is more regularly written as:
allow write: if request.auth.uid == request.resource.data.author;
The difference when using request is that it explicitly refers to the document (resource) that is in the write request. The result is the same here whether we use resource or request.resource, but I find it easier to see how security works when thinking of the request here.
I was learning through official doc for security rules, but i cant make it work.
in my collections users under document user have some map values, one of them is role: "guest". role values can be "guest" or "superAdmin"
i want access to /users only when role == "superAdmin"
here is what i tried
service cloud.firestore {
match /databases/{database}/documents {
match /users/{userId} {
allow read: if get(/databases/$(database)/documents/users/$(userId)).data.role == "superAdmin";
}
}
}
and got error when i log in as superAdmin
ERROR Error: Missing or insufficient permissions.
i believe i followed docs correctly. and found a similar question in SO where says some bug specific to evaluating nested fields in queries. But i have no nested queries. am i doing anything wrong here?
here is my firestore look
Please help.
Instead of using get(), since you're fetching the document at the location you're reading from, simply address it using resource (which is the prefetched document at that location):
service cloud.firestore {
match /databases/{database}/documents {
match /users/{userId} {
allow read: if resource.data.role == "superAdmin";
}
}
}
Only use get() if you're going to a different collection to fetch data.
I think the part that breaks it is allow read: if get(/databases/$(database)/documents/users/$(userId)). Here you are comparing the owner of the document, not the one requesting it. Try replacing userID with request.auth.uid.