Firebase security rules check: fix "test mode" and "insecure rules" in an AI-built app

Firebase lets your app talk to the database straight from the browser. That is fine when your security rules are strict. It is a problem when the rules still say anyone can read and write, which is common in apps that started in test mode or were set up by an AI tool. Here is how to check yours and what to paste instead.

1. Your Firebase apiKey is not the problem

Many people panic when they see apiKey: "AIza…" in their site's JavaScript. Firebase's own docs say the API keys for Firebase services are public by design. They identify your project. They do not grant access to your data. Access is controlled by Firebase Security Rules (and App Check).

So the real question is not “is my key visible?” It is “what do my rules let a stranger do with it?” One exception: keys for other services are secrets. Firebase's docs single out the Gemini Developer API key. It should never be in browser code or in the allowlist of a public key.

2. The rules that leave your data open

Look for any of these in the Firebase console (Firestore Database, Realtime Database and Storage each have a Rules tab) or in your project files.

Test mode (Firestore or Storage). Anyone can read and write everything until the date. After that date, all client requests are denied and your app stops working:

match /{document=**} {
  allow read, write: if request.time < timestamp.date(2026, 12, 1);
}

Open to everyone. No date, no limit:

allow read, write: if true;

Realtime Database open rules, in database.rules.json:

{
  "rules": {
    ".read": true,
    ".write": true
  }
}

Signed-in is not the same as allowed. This looks safer, but anyone who creates an account can read or overwrite every document:

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

3. Rules to use instead

Write one match block per collection and say who may do what. Anything you do not list is denied. Here is a common setup: each user owns their own profile and notes, and published posts are public to read.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Each user can read and change only their own profile
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
    // Notes store their owner's uid in an ownerId field
    match /notes/{noteId} {
      allow read, update, delete: if request.auth != null && resource.data.ownerId == request.auth.uid;
      allow create: if request.auth != null && request.resource.data.ownerId == request.auth.uid;
    }
    // Anyone can read published posts. Nobody can write from the browser.
    match /posts/{postId} {
      allow read: if resource.data.published == true;
      allow write: if false;
    }
  }
}

For Storage, keep each user's files under a folder named after their uid:

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/{allPaths=**} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Adjust the collection names and fields to your app. Admin-only actions, like deleting any user, belong in server code (Cloud Functions or a server using the Admin SDK), not in rules that open writes to the browser.

4. Test before you publish

• In the Firebase console, open the Rules Playground on the Rules tab. Try a read and a write as a signed-out user, as the owner and as a different signed-in user.
• Or run the Firebase Local Emulator Suite and test your app against the new rules.
• Publish, then click through your app to confirm everything still works.

5. Keep the rules in your project

If your rules only live in the console, an AI tool cannot see them and you cannot review changes. Keep them in firestore.rules, storage.rules and database.rules.json, and deploy them with:

firebase deploy --only firestore:rules,storage,database

Paste this into Cursor, Lovable, Bolt or another AI tool to review your project:

I'm not a developer, so please explain what you change in simple words. My app uses Firebase from the browser. I want to make sure my Firestore, Realtime Database and Storage security rules don't let strangers read or change data.

Please:
1) Find my rules files (firestore.rules, storage.rules, database.rules.json, or the rules in firebase.json). If they only exist in the Firebase console, tell me how to copy them into my project.
2) List every collection or path my app reads or writes, and who should be allowed: anyone, signed-in users, only the owner of the document, or server code only.
3) Remove any rule that allows everything: "allow read, write: if true", "if request.time < timestamp.date(...)" (test mode), ".read": true / ".write": true, or a catch-all match /{document=**} that only checks request.auth != null.
4) Write per-collection rules. Owner data should use request.auth.uid == userId (or a field like resource.data.ownerId). Public data can allow read, but not write. Everything else should be denied by default.
5) Tell me how to test the rules (Rules Playground or the Firebase emulator) as a signed-out user, the owner and a different signed-in user, and how to deploy them with firebase deploy --only firestore:rules,storage,database.
6) Check that no secret keys (for example a Gemini, OpenAI or Stripe secret key) are in my browser code. The Firebase web config apiKey is fine to leave in.

Make the smallest safe change, don't break existing features, and don't delete any data. When you're done, tell me in plain English what you changed.

6. How Cheqvo helps

A Cheqvo repo scan reads the Firebase rules files committed to your repo and flags rules that allow everyone, test mode date rules, and catch-all rules that only check that a user is signed in. A live-site scan can tell that your app uses Firebase, but it cannot read your rules from outside, so it reminds you to check them. It also looks for secret keys in your JavaScript bundles. For Supabase apps, see our guide on checking Row Level Security.

Quick answers

General guidance. A fast automated check for the most common security mistakes in AI-built apps. Not a substitute for a full security audit. Updated 2026-11-02.

All guides · Home · Terms · Privacy