CODEWITHSUNDEEP
firebasegoogle-cloud-firestorefirebase-authenticationfirebase-security
Wooble
Wooble

Reputation: 166

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:

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?

Upvotes: 4

Views: 1607

Answers (1)

Frank van Puffelen
Frank van Puffelen

Reputation: 600110

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.

Upvotes: 2

Related Questions