Firestore permission-denied errors: the fix

Short answer: Your Firestore Security Rules are denying the request, so the whole request is rejected. Fix it by writing rules that match your data paths and the signed-in user, testing them in the rules simulator, then publishing them.

Why it happens

This applies to apps made with AI app builders (such as Lovable, Bolt, Base44, Replit or v0) that use Firebase and Cloud Firestore as the backend.

Every database request from the Cloud Firestore mobile/web client library is checked against your security rules before any data is read or written. If the rules deny access to any document path in the request, the whole request is denied.

Rules are built from match statements that identify documents, plus allow expressions that control access to them. When the auth variable is null (the user is not signed in), any rule that requires request.auth != null will deny the request.

Two rule patterns that can cause this:

• Deny all. allow read, write: if false; denies every user under any conditions.
• Signed-in only, wrong path. A rule like allow read, write: if request.auth != null; on match /{document=**} allows any signed-in user, but a narrower rule such as match /users/{userId} with request.auth.uid == userId will deny anyone whose uid does not match the document name.

Also note: server client libraries bypass all Cloud Firestore Security Rules and authenticate with Google application default credentials instead. If your app calls Firestore from a server client library or the REST or RPC API, check that Identity and Access Management (IAM) is set up for Cloud Firestore.

How to fix it

1. Open the Firebase console and go to Databases & Storage > Firestore > Rules tab. If you have more than one database, use the database selector to pick the one your app uses.
2. Read the current rules. If you see allow read, write: if false;, that is the deny-all set and it blocks every request.
3. Write rules that match your real data paths and the signed-in user. For per-user documents, the documented pattern is:
   • match /users/{userId}
   • allow read, write: if request.auth != null && request.auth.uid == userId;
4. If you want to use collection group queries, add rules_version = '2'; as the first line of the rules file. Version 2 changes how the recursive wildcard {name=**} works, and you must opt in to it.
5. Test before publishing. The simulator runs against the rules in your editor, not the deployed rules. You can use either console:
   • Firebase console: on the Rules tab, click Rules Playground to open the simulator settings, choose your simulation options, then click Run.
   • Google Cloud console: go to the Databases page, click the ID of the database you want to test, click Security in the navigation menu, then click the Simulator tab. You need the IAM permission firebaserules.rulesets.test.
6. In the Google Cloud console simulator, set it up like this:
   • In the simulation type drop-down, pick an operation type: get, create, update or delete.
   • Enter the document path in the location field, for example users/user_123.
   • For create and update requests, optionally click Create document to configure a mock document payload.
   • To simulate an authenticated request, optionally turn on Authenticate, choose the provider (for example google.com or Anonymous), and configure the token payload fields.
   • Click Run. The evaluation panel shows whether the request is allowed, with a detailed report for each condition checked and line-level highlighting in the code editor.
7. Click Publish in the online editor of the Firebase console to deploy the rules. The Google Cloud console cannot deploy rules to the (default) database; use the Firebase console or the Firebase CLI for that database.
8. If you deploy rules with the Firebase CLI instead, run firebase init firestore to create a .rules file, edit it, then run firebase deploy --only firestore. Rules deployed with the CLI overwrite any rules in the Firebase console, so keep the file in your project directory updated if you also edit in the console.
9. Allow up to a minute for rule updates to apply to new queries and listeners. Changes can take up to 10 minutes to fully take effect and affect anyone listening on live streams.
10. If your app reads or writes Firestore from a server client library, REST or RPC API, set up IAM for Cloud Firestore. The predefined role roles/datastore.user gives read/write access to data in a Cloud Firestore database and is intended for app developers and service accounts. Cloud Firestore caches IAM permissions for 5 minutes, so a role change can take up to 5 minutes to take effect.

How to check it worked on your live app

Open a private browser window and sign in with a fresh email address. Do the exact action that failed before, such as saving a document or loading the list that showed the error. If the action now completes, the rules are allowing that request. Then repeat the same action while signed out, to confirm your rules still deny what they should.

Prompt to paste into your AI builder

Paste this into your AI builder: "My Firebase app shows a permission-denied error when it reads or writes Firestore. Show me the current Firestore Security Rules first, then change them so they match my actual collection paths and the signed-in user, using request.auth != null && request.auth.uid == userId for per-user documents. If I use collection group queries, add rules_version = '2'; as the first line. Do not use allow read, write: if true; anywhere. Show me the diff before applying it, and tell me which document path each rule covers."

FAQ

Why does one denied path reject my whole request? Because Cloud Firestore evaluates every database request from the mobile/web client library against your rules, and if the rules deny access to any document path in the request, the entire request is denied.

Can I just allow everything to make the error go away? The documented allow-all set is allow read, write: if true;, and the Firebase docs warn never to use it in production because it lets anyone overwrite your entire database.

Why do my rules work in the simulator but not in the app? The simulator runs against the rule set in your editor, not the deployed rule set. Publish the rules, then allow up to a minute for new queries and listeners to pick them up.

Why does my server-side code still fail after I fix the rules? Server client libraries bypass all Cloud Firestore Security Rules and authenticate with Google application default credentials. For those, set up IAM for Cloud Firestore instead.

Related guides

• Data won't save: 'new row violates row-level security policy' — the same class of database permission error on a different backend.
• Users can see other users' data in my Lovable app: find it and lock it down — why per-user rules matter, not just any rule that lets the request through.
• The AI says it fixed it, but it's still broken: how to stop the loop — useful when a rules change is claimed but not published.

Sources

• Get started with Cloud Firestore Security Rules
• Security Rules and Firebase Authentication
• Identity and Access Management (IAM) for Firestore

VibeFix's AI agent signs up to your live app like a new person and shows whether sign-up and your pages work. It may not show Firestore rules rejecting reads and writes directly. VibeFix checks; it does not fix your app.

Last checked: 18 October 2026, against the sources listed above.

VibeFix is independent. Lovable, Bolt, Replit, Base44, v0 and Supabase are trademarks of their owners.