How to fix Permission denied. User does not have permission to access document in Firebase

FirebaseINTERMEDIATEHIGHUpdated Dec 22, 2025· 244 views

This error occurs when a user lacks authorization to read or write a specific Firestore document. It's caused by security rules denying access, unauthenticated users, or insufficient user permissions. Fix it by reviewing security rules, ensuring proper user authentication, and configuring rules to grant appropriate access.

Quick fix

Fixes PERMISSION_DENIED

import { getAuth, onAuthStateChanged } from "firebase/auth";
import { getFirestore, doc, getDoc } from "firebase/firestore";

const auth = getAuth();
const db = getFirestore();

onAuthStateChanged(auth, async (user) => {
  if (user) {
    // User is authenticated, safe to access Firestore
    const docRef = doc(db, "users", user.uid);
    const docSnap = await getDoc(docRef);
    console.log(docSnap.data());
  } else {
    console.log("User not authenticated");
  }
});
  1. Verify the user is authenticated before accessing Firestore
  2. Review and update Firestore security rules
  3. Test rules using the Firestore Rules Playground
  4. Check that your app sends the correct user context
firebase — error
import { getAuth, onAuthStateChanged } from "firebase/auth";
import { getFirestore, doc, getDoc } from "firebase/firestore";
const auth = getAuth();
const db = getFirestore();
onAuthStateChanged(auth, async (user) => {
  if (user) {
    // User is authenticated, safe to access Firestore
    const docRef = doc(db, "users", user.uid);
    const docSnap = await getDoc(docRef);
    console.log(docSnap.data());
  } else {
    console.log("User not authenticated");
  }
});
Permission denied. User does not have permission to access document

What this error means

This error means Firebase Firestore has rejected your read or write operation because the security rules do not permit the current user to access that document. Firestore enforces security rules server-side before any data operation occurs—no client-side workaround can bypass them. The error typically indicates one of three issues: (1) the user is not authenticated when the rules require it, (2) the security rules explicitly deny access to the requested document or collection, or (3) the user's identity (UID, email, or custom claims) doesn't match the rule conditions required for access. Unlike the Realtime Database, Firestore permission denied errors are document-specific. You might have access to one document but not another, depending on your security rules and the document's path or data.

Typical symptoms

  • Firestore read or write operations fail with "PERMISSION_DENIED" or "Missing or insufficient permissions" error
  • Error appears as: "FirebaseError: Missing or insufficient permissions" or "Error: 7 PERMISSION_DENIED"
  • Operations work in Firebase Console (authenticated as project owner) but fail in your app
  • Some documents load but others return permission denied on the same collection
  • Database access succeeds for one user but fails for another user
  • Error occurs only after authentication, not before

Common causes

  1. User is not authenticated when security rules require auth (most common)
  2. Security rules explicitly deny read/write access to the document path
  3. User is authenticated but their UID or email doesn't match rule conditions
  4. User lacks required custom claims that rules check for (e.g., role: "admin")
  5. Rules check for document fields that don't exist or have unexpected values
  6. Attempting to read/write a document in a collection with no matching rules
  7. Security rule conditions are malformed or have syntax errors

How to fix "Permission denied. User does not have permission to access document"

1Verify the user is authenticated before accessing Firestore

Always check that the user is logged in before attempting database operations. Use onAuthStateChanged() to wait for authentication to complete:

javascript
import { getAuth, onAuthStateChanged } from "firebase/auth";
import { getFirestore, doc, getDoc } from "firebase/firestore";

const auth = getAuth();
const db = getFirestore();

onAuthStateChanged(auth, async (user) => {
  if (user) {
    // User is authenticated, safe to access Firestore
    const docRef = doc(db, "users", user.uid);
    const docSnap = await getDoc(docRef);
    console.log(docSnap.data());
  } else {
    console.log("User not authenticated");
  }
});

Never attempt Firestore operations in the root of your app or before onAuthStateChanged fires.

2Review and update Firestore security rules

Go to Firebase Console > Firestore Database > Rules tab. The most common pattern is allowing users to read/write only their own documents by matching UID:

bash
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{uid} {
      allow read, write: if request.auth.uid == uid;
    }
  }
}

This rule allows users to access /users/{uid} only if they're authenticated and their UID matches the document ID.

For public collections, you might allow authenticated reads:

bash
match /public/{document=**} {
  allow read: if request.auth != null;
  allow write: if false;
}

Never use this for production:

bash
match /{document=**} {
  allow read, write: if true;
}

This makes your database publicly readable and writable—attackers can delete all your data.

3Test rules using the Firestore Rules Playground

In Firebase Console, go to Firestore > Rules and click the "Rules playground" button (or refresh after editing rules). Test if your rules allow the operation:

1. Click "Simulate read" or "Simulate write"
2. Enter the document path (e.g., users/user123)
3. Scroll down to the "Authentication" section and set the user UID:
 - Click Edit next to Authentication
 - Paste: { "uid": "user123" }
4. Click "Run"

The playground will tell you which rule lines allowed or denied the operation. Fix any issues before publishing.

4Check that your app sends the correct user context

Firestore passes the authenticated user information to your rules via request.auth. Make sure your app is signed in correctly:

javascript
import { getAuth, signInWithEmailAndPassword } from "firebase/auth";
import { getFirestore, doc, setDoc } from "firebase/firestore";

const auth = getAuth();
const db = getFirestore();

// 1. Sign in the user
await signInWithEmailAndPassword(auth, email, password);

// 2. Get the authenticated user
const user = auth.currentUser;
console.log("Signed in as:", user.uid);

// 3. Now try to write to Firestore
if (user) {
  const userRef = doc(db, "users", user.uid);
  await setDoc(userRef, {
    email: user.email,
    createdAt: new Date()
  });
}

If auth.currentUser is null or undefined, the write will be rejected because request.auth will be empty in your rules.

5For rules that check custom claims, verify they are set

If your rules check for custom claims (e.g., role: "admin"), ensure the claims are set on the user's token:

bash
// Rule that checks custom claims
match /admin/{document=**} {
  allow read: if request.auth.token.admin == true;
}

Custom claims must be set from a backend using Firebase Admin SDK, not from the client:

javascript
// Backend only (Node.js, Cloud Function, etc.)
const admin = require('firebase-admin');

const uid = 'user123';
await admin.auth().setCustomUserClaims(uid, { admin: true });

console.log('Custom claims set for user:', uid);

After setting custom claims, the user must sign out and sign back in for the claims to appear in their ID token. Client-side SDKs cannot set custom claims—attempting to do so is a security vulnerability.

6For complex rules, test with different user contexts

If your rules have multiple conditions or roles, test each scenario in the playground:

bash
// Example rule with multiple conditions
match /documents/{documentId} {
  allow read: if request.auth != null &&
              request.auth.token.role in ['admin', 'editor'];
  allow write: if request.auth.uid == resource.data.owner &&
               request.auth.token.role == 'admin';
}

Test each scenario:
- Unauthenticated user: Leave Authentication empty, expect Deny
- Regular user: Set { "uid": "user1", "token": { "role": "user" } }, expect Deny
- Editor user: Set { "uid": "user2", "token": { "role": "editor" } }, expect Allow for read only
- Admin user: Set { "uid": "doc_owner_id", "token": { "role": "admin" } }, expect Allow for write

Advanced notes

Rule Propagation Delay: Updates to Firestore security rules can take up to a minute to affect new queries and listeners. If you just published new rules, wait a moment before testing—the error might be cached.

Not a Filter: Security rules are not query filters. You cannot write a query for all documents in a collection and expect Firestore to return only the ones you have permission to access. If any document in the result set is denied, the entire query fails with permission denied. Design queries to match your rule structure.

Service Account Access: If you're accessing Firestore from a backend (Node.js, Cloud Functions), use Firebase Admin SDK with a service account. Service accounts bypass client-side security rules:

javascript
const admin = require('firebase-admin');
admin.initializeApp();
const db = admin.firestore();

// This bypasses security rules
await db.collection('users').doc('user123').set({
  name: 'John',
  role: 'admin'
});

Service accounts use IAM permissions instead of Firestore rules. Always use the least-privilege principle when granting service account roles.

Debugging with Logs: Enable debug logging to see exactly why a rule denied access:

javascript
// In development only
import { enableLogging } from "firebase/firestore";
enableLogging(true);

Check your browser console for detailed rule evaluation messages.

Testing with Firebase Emulator: For local development, use Firebase Emulator Suite to test rules without affecting production:

bash
firebase emulators:start

The emulator lets you iterate on security rules quickly without deployment delays.

Frequently asked questions

What does "PERMISSION_DENIED" mean?
This error means Firebase Firestore has rejected your read or write operation because the security rules do not permit the current user to access that document. Firestore enforces security rules server-side before any data operation occurs—no client-side workaround can bypass them. The error typically indicates one of three issues: (1) the user is not authenticated when the rules require it, (2) the security rules explicitly deny access to the requested document or collection, or (3) the user's identity (UID, email, or custom claims) doesn't match the rule conditions required for access.
How do I fix "PERMISSION_DENIED"?
This error occurs when a user lacks authorization to read or write a specific Firestore document. It's caused by security rules denying access, unauthenticated users, or insufficient user permissions. Fix it by reviewing security rules, ensuring proper user authentication, and configuring rules to grant appropriate access.
What causes "PERMISSION_DENIED"?
User is not authenticated when security rules require auth (most common) Security rules explicitly deny read/write access to the document path User is authenticated but their UID or email doesn't match rule conditions
Is the "PERMISSION_DENIED" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading