AppInspected

Fix guides

Your Firestore database is still in test mode. Here's how to lock it down.

Last reviewed October 16, 2026 against the providers' current documentation.

The short version

If your Firestore rules say allow read, write: if true, or only check a date, anyone who finds your project ID can read, change or delete everything. Replace them with rules that tie each document to the signed-in user, test them in the Rules Playground or the emulator, and deploy.

Why it matters

Firebase's docs describe test mode as a starting point that lets anyone read and overwrite your data. Your web app talks to Firestore straight from the browser, and the Firebase config (including the project ID) is in your JavaScript by design. Security Rules are the only thing standing between that config and your data.

Fix it, in this order

  1. Look at your current rules

    In the Firebase console, open Firestore → Rules. If your project manages rules with the Firebase CLI, open the rules file named in firebase.json instead, because the next deploy will overwrite the console. Open rules look like this:
    match /{document=**} {
  allow read, write: if true;
}
    A rule that only checks a date, such as allow read, write: if request.time < timestamp.date(2026, 11, 15);, is the same thing with a deadline: open to everyone until that date, then closed to everyone, which breaks your app.

  2. Also watch for "any logged-in user"

    Firebase lists allow read, write: if request.auth != null; as not recommended: it lets any signed-in user, including one who just made an account, read and write the whole collection. Narrow it to the data each user owns.

  3. Write owner-only rules

    This follows the content-owner pattern in Firebase's docs. Each document stores the user ID of its owner in a field such as author_uid:
    rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /notes/{noteId} {
      allow read, delete: if request.auth != null
        && request.auth.uid == resource.data.author_uid;
      allow create: if request.auth != null
        && request.auth.uid == request.resource.data.author_uid;
      allow update: if request.auth != null
        && request.auth.uid == resource.data.author_uid
        && request.auth.uid == request.resource.data.author_uid;
    }
  }
}
    The update rule checks both the old and new document so nobody can hand a document to someone else. Add a match block for each collection your app uses; anything without a matching rule is denied.

  4. Test before you deploy

    In the console's Rules tab, open the Rules Playground and simulate a signed-out read, a read of your own document, and a read of someone else's. For automated tests, Firebase recommends the Local Emulator Suite.

  5. Deploy the rules

    Publish from the console, or with the CLI run firebase deploy --only firestore. Firebase says new rules can take up to a minute to apply to new queries and up to 10 minutes to reach listeners that are already open.

  6. Remember Storage and server code

    Cloud Storage has its own rules: check them the same way. Code that uses the Firebase Admin SDK or server client libraries skips Security Rules entirely and is controlled by IAM, so keep those credentials on the server.

Or ask your AI tool to do it

Paste this into Lovable, Bolt, Cursor, Claude Code or whichever tool built your app. Review what it changes before you deploy.

My Firestore security rules are still in test mode (allow read, write: if true, or only a date check). Replace them with rules_version = '2' rules that deny everything by default and, for each collection the app uses, only let a signed-in user read, create, update and delete documents they own (request.auth.uid must match the owner field on the existing and the new document; ownership must not change on update). Anything that is meant to be public must be read-only. Make sure the app writes the owner field on every document it creates. Do not use request.auth != null on its own. Show me the collections you found, the final firestore.rules file, and the Rules Playground cases I should run before I deploy.

How this happens

Test mode is the quickest way to make a new Firebase app work, so it's what many tutorials and AI builders start with. The app then ships before anyone comes back to write real rules.

Check what your app exposes

The free check reads your live site the way an attacker would: it finds which Firebase project your app talks to and flags any secret key in your JavaScript. To test the Firestore rules themselves, add the database tests to the website security report.

Check my app free

Questions

My test-mode rules have an expiry date. Isn't that safe?

No. Until the date passes, anyone can read and overwrite your data. After it passes, your own app stops working too. Neither is what you want in production.

Is my Firebase API key in the frontend a problem?

No. The Firebase web config is meant to be public. Your rules are what protect the data.

Can AppInspected test my Firestore rules?

The free check only reads what a browser can see, so it can tell you which Firebase project your app uses but not whether the rules are safe. The website security report can add database tests that check the rules using your own test accounts, with writes tested only in the Firebase Rules Emulator.

Sources

Related guides