Firebase security rules for beginners

If your app uses Firebase, there's a block of settings in your code with an apiKey, a projectId, and maybe a databaseURL. A lot of people panic when they notice that anyone can see it. You don't need to. That config is meant to be public, and hiding it wouldn't protect anything.

What protects your data is a separate thing called Firebase Security Rules. This guide explains what they are, how to read yours, and what a safe starting point looks like.

Why the config isn't the problem

Your app talks to Firebase straight from the visitor's browser, so the browser needs to know which project to talk to. That's all the config is: an address. Firebase's docs say the web API key isn't a secret in the usual sense. It's still worth restricting it to your domain in Google Cloud, so nobody else can run up usage on it, but it isn't what keeps your data private.

Rules decide who can read and write which data. Firebase has separate rules for each product you use:

• Cloud Firestore (the most common database)
• Realtime Database (the older one, with a databaseURL)
• Cloud Storage (uploaded files and images)

Each one needs its own check.

What "test mode" really means

When you create a Firestore database, Firebase asks whether to start in production mode (deny everything) or test mode. Firebase's docs say test mode "allows anyone to read and overwrite your data."

The test mode rule looks like this:

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

That means "anyone on the internet can read, change, and delete everything until this date." The console sets the date about 30 days ahead. After it passes, every request from your app is denied, which is why some apps suddenly stop working a month after launch. Firebase emails you before it happens.

The tempting fix is to push the date forward. Don't. That just keeps the door open longer. The real fix is to replace the rule.

How to read your rules

1. Open the Firebase console and pick your project.
2. Open Firestore (or Realtime Database, or Storage).
3. Click the Rules tab.

Look for these patterns. Firebase's own guide to insecure rules lists them as common mistakes:

• allow read, write: if true; means anyone can do anything.
• A request.time < date rule like the one above means anyone can do anything until that date.
• allow read, write: if request.auth != null; on everything means any signed-in user can read every other user's data. Since anyone can sign up, that's not much better than open.
• In Realtime Database, ".read": true or ".write": true at the top level opens the whole tree.

A safe starting point

The pattern Firebase recommends for most apps is "content owner only." Each user can read and write their own data, and nobody else's. For Firestore, if each user's data lives under users/{their id}:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId}/{document=**} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Anything you don't list is denied by default. If your app has public data, like blog posts or a product list, add a separate rule that allows reading that collection and keeps writing limited to you or the owner.

For Realtime Database, the same idea:

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth != null && auth.uid === $uid",
        ".write": "auth != null && auth.uid === $uid"
      }
    }
  }
}

One thing that trips people up in Realtime Database: rules cascade down. If a parent path allows a read, you can't take it away at a child path. Keep the top level closed and open up specific paths.

Don't forget Storage. Uploaded photos, documents, and avatars have their own rules tab, and an open bucket is a separate leak from an open database.

Letting your AI tool write them

If an AI tool built your app, it knows how your data is laid out better than a template does. A prompt that works:

Replace my Firestore, Realtime Database, and Storage security rules. Remove any rule that allows access to everyone or any rule with a request.time date. Each user should only read and write their own data. List any collection that needs to be public and explain why before you open it. Don't use the Firebase Admin SDK or a service account key in frontend code.

Then read what it wrote. If you see if true or a date rule, it isn't done.

Test before and after you publish

• The Rules Playground in the console (under the Rules tab) lets you simulate a read as a signed-out visitor or as a specific user before you publish a change.
• After publishing, open your app in a private window, sign up as a second person, and try to view the first person's data.
• If your app breaks after tightening rules, that's usually a sign it was reading data it shouldn't. Fix the query, not the rule.

The short version

• The Firebase config is public by design. Rules protect your data.
• Test mode rules leave everything open until a date. Replace them, don't extend them.
• request.auth != null alone isn't enough for private data.
• Check Firestore, Realtime Database, and Storage separately.

The free Throttle Bird scan notices when your page ships a Firebase config. After you prove you own the app, it tries one signed-out read of your Realtime Database root and one Firestore list of a single document, and tells you in plain words whether a stranger got anything back. It never writes, and it never stores the documents or values it sees.

Sources: Firebase: Avoid insecure rules, Firebase: Basic security rules, Firebase: Learn about using and managing API keys.