Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Firestore security rules: allow access to one specific user

I have a production and a sandbox Firestore databases and a common firestore.rules file.
I want only one user per database to be allowed to read and write.

I've currently using this configuration for the security rules

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
  
    function isAdmin(uid) {
      return uid == "IKHXrLmfIFZvrimpJUwnfUzTUoE2" 
      || uid == "xVTByGu49XX3rOdNYMKf2Bzt5bY2";
    }
    
    match /{document=**} {
      allow read, write: if isAdmin(request.auth.uid)
    }
  }
}

The first uid is the demo user (which exists only in the sandbox firebase project) and the second one is the admin user of the production database (which exists only in the production project)

Details:

  • The codebase is open
  • The sandbox database has public api key and demo user credentials (free plan).
  • The production database is private, api key and admin credential are protected.

I am aware that publishing the sandbox API key is not the best, but it's not an important database.
The important thing is that the production database remains safe.

Are there any security issues using this method? If yes, how can I protect the production database?

like image 364
Wooble Avatar asked Oct 15 '25 01:10

Wooble


1 Answers

I use this approach all the time when I first start on a project. I create an initial (anonymous) user, and give that one extensive permission in the security rules.

Since you'd need the project's service credentials to be able to set the same UID at will on my project, this approach is secure and allows me to get started quickly.

Then when I'm ready for a more extensive security system I extend the security model, typically on one of these:

  1. By allowing all users from a specific domain administrative access.
  2. By creating a list of admin UIDs in the database, and checking that in my rules.
  3. By adding a custom claim isAdmin to the user's token, and check that in the security rules.

But even at that point, I tend to leave the hard-coded UIDs in place, as they are no security risk.

like image 145
Frank van Puffelen Avatar answered Oct 18 '25 04:10

Frank van Puffelen



Donate For Us

If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!