Firestore Security Rules. Is it Okay for users to know peoples UID?

Question

So I have a collection right now, structured in the following way

Companies (Collection) -> Company (Document) -> Document has data including the auth UID, plus a subcollection called employs, which has individual employ documents if that makes sense.

I have two questions.

1. Basically, I want any authenticated user to be able to read the data, therefore any user, if he wants to can read a companies uid, and other data including that which is in the subcollection employs. But for write permissions, I only want the company to be able to edit their own documents and its employ subcollection documents. So in order to accomplish this I am using the following security code

match /databases/{database}/documents {

    match /companies/{companyID} {
        allow read: if request.auth.uid != null;
        allow create,update: if request.auth.uid == resource.data.uid && request.auth.uid == request.resource.data.uid 
        allow delete: if request.auth.uid == resource.data.uid
    }
    match /companies/{companyID}/employs/{employID}{
        allow read: if request.auth.uid != null
        allow write: if request.auth.uid == get(/databases/$(database)/documents/brands/$(document)).data.uid && request.auth.uid == request.resource.data.uid 

    }

  }

So my first question is that, is it fine for other users to be able to read other users UID, because I dont know of a different way to handle write permissions, as I am currently checking to see if the doc id matches the request.auth.uid. In the documentation, they seem to do it similarily. But I just had to make sure that it is fine for user uids to be "public".

Secondly is my implementation right? Is there anything else I should do to achieve the desired results? Please give feedback or suggestions, thanks!

Answer 1

If your security rules are set up correctly, it typically doesn't matter if a UID is known. You'll have to assess that for yourself, however. We can't say for sure without seeing all of the ways you use it in your system.

You'll have to think about it this way: If an arbitrary users know another arbitrary user's UID, what could be known about that other person? If it's possible to get personally identifiable information without their consent, you should probably correct that. If the user's data could be changed any way (again, without their consent), then you also have a problem.

The UID itself doesn't contain any information. It's just a random string. It can't possibly be "spoofed" by an incoming request. request.auth.uid is always going to be the correct UID for the signed in user, and no one else.

Your rules look OK, but I strongly suggest testing them using the local emulator . You can verify for yourself that they do exactly what you expect, using test code you write.