Firebase通过UID设置版主权限是否安全？是否需令牌认证分配角色？

Great question! Let’s break this down into two clear parts: whether hardcoding a specific UID in your Firebase security rules is secure, and if token-based role authentication is mandatory for moderators.

Short answer: Yes, it’s technically secure—but it has significant limitations for anything beyond a single, static trusted user.

Why it’s secure #

Firebase Authentication guarantees that auth.uid is a verified, unforgeable value. A user can only get an ID token with a specific UID if they hold valid credentials (like email/password, Google sign-in) for that exact account. Unless someone steals the target user’s login details, they can’t impersonate them to gain write access. Your current rule write: "auth != null && auth.uid === 'h7yic7LeS123asdfsdgwPrfKZ2'" is totally safe for a single trusted editor.

The big drawbacks #

• No scalability: If you need to add more moderators later, you’ll have to manually update your rules with additional || auth.uid === 'another-uid' clauses. This gets messy fast with even a handful of users.
• Manual maintenance: If a moderator leaves or their access needs to be revoked, you have to edit and redeploy your security rules. There’s no way to make this change dynamically without touching the rules.

No, it’s not mandatory—but it’s the most scalable and maintainable approach for most production cases. Here are your options:

Option 1: Stick with hardcoded UIDs (for tiny, static teams) #

As we said, this works if you only ever need one trusted user. It’s simple and secure for that narrow use case.

Option 2: Store moderator UIDs in your database #

Create a moderators node in your Firebase Database that lists all approved UIDs, then update your rules to check if the user’s UID exists there:

{
  "rules": {
    "sensitive-data": {
      ".write": "auth != null && exists(/databases/$(database)/documents/moderators/$(auth.uid))"
    }
  }
}

• Pros: You can add/remove moderators dynamically by editing the moderators node (no rule redeploys needed).
• Cons: You have to lock down the moderators node itself (make sure only admins can write to it), and rule checks that read from the database have minor performance overhead (though Firebase optimizes this well).

Option 3: Use custom claims (token-based roles) #

This is the recommended approach for most production scenarios. Custom claims are key-value pairs you attach to a user’s ID token via the Firebase Admin SDK. For example, set a role claim of moderator for trusted users:

// Run this on your backend (Firebase Cloud Functions or your own server)
admin.auth().setCustomUserClaims('h7yic7LeS123asdfsdgwPrfKZ2', { role: 'moderator' })
  .then(() => {
    // Claim successfully applied
  });

Then update your rules to check for this claim:

{
  "rules": {
    "sensitive-data": {
      ".write": "auth != null && auth.token.role === 'moderator'"
    }
  }
}

• Pros:
  • Claims are stored in the ID token, so rule checks are fast and don’t require database reads.
  • Manage roles dynamically via your backend (no rule changes needed to add/remove moderators).
  • Supports complex role structures (e.g., admin, moderator, editor) if you need them later.
• Cons: Requires setting up a backend to manage custom claims, but this is straightforward with Firebase Cloud Functions.

If you only need one trusted editor, hardcoding the UID is totally fine. But if you expect to add more moderators or need to adjust access dynamically, go with custom claims—it’s the most robust long-term solution. Storing moderators in the database is a solid middle ground if you don’t want to set up a backend yet, but custom claims are better for scalability.

内容的提问来源于stack exchange，提问作者Mr. Blockchain