Firebase Storage storage/unauthorized Error

General
1

I’m encountering a persistent storage/unauthorized error when trying to upload files to Firebase Storage. My Storage security rules are designed to allow writes based on user roles fetched from Firestore using the get()function.

Details:

  1. Client-Side Confirmation: My Next.js application correctly authenticates the user and confirms their role via AuthContext by reading their profile from Firestore (e.g., /users/USER_UID shows role: "super-admin").
  2. Firestore Data: I have meticulously verified that the user document in Firestore (e.g., /users/USER_UID) exists and has the role field correctly set to the appropriate string value (e.g., "super-admin").
  3. Firestore Security Rules: My Firestore rules allow an authenticated user to get their own user document (i.e., allow get: if request.auth.uid == userId; within match /users/{userId}).
  4. Firebase Storage Security Rule (Example for /appTheme path):
match /appTheme/{imageName} {
  allow read: if true;
  allow write: if request.auth != null &&
                  get(/databases/(default)/documents/users/$(request.auth.uid)).data.role in ['super-admin', 'school-admin'];
}
  1. Error: Despite the above, file uploads to paths protected by this rule fail with storage/unauthorized.
  2. Working Diagnostic Rule: A simplified Storage rule that only checks request.auth.uid (without the Firestore get() call) does allow the upload for the same authenticated user. For example: allow write: if request.auth != null && request.auth.uid == 'SPECIFIC_USER_UID'; works.

Problem: The issue seems to be that the get(/databases/(default)/documents/users/$(request.auth.uid)).data.role expression within the Firebase Storage security rule is not correctly evaluating or retrieving the user’s role from Firestore, even though the data exists and is accessible by the client application. This leads to the storage/unauthorized error.

I’m looking for insights into why this cross-service get() call from Storage rules to Firestore might be failing to confirm the user’s role, or common pitfalls in such rule configurations.

Thank you