Firebase Security Rules: What Vibe Coders Get Wrong

The short version

Firebase Security Rules are the access control layer for your Firebase project. They determine who can read, write, update, and delete data in Firestore, Realtime Database, and Cloud Storage. If your rules are too permissive, your entire database is an open book.

The Firebase Security Rules documentation says it plainly: "Security Rules stand between your data and malicious users."

The dangerous default

When you start a new Firebase project, the console often suggests starting in "test mode":

// Firestore test mode rules
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.time < timestamp.date(2026, 4, 22);
    }
  }
}

This allows anyone to read and write everything for 30 days. The intention is to let you prototype without worrying about rules. The problem is that developers ship to production and forget to tighten them.

After that 30-day timestamp passes, the rules lock down completely (deny all). So apps either break or developers extend the date. Both outcomes are bad.

How Security Rules work

Rules are declarative. You define patterns that match document paths and conditions that must be true for access:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    // Users can only read and write their own profile
    match /users/{userId} {
      allow read, write: if request.auth != null
                         && request.auth.uid == userId;
    }

    // Posts are readable by everyone, writable by the author
    match /posts/{postId} {
      allow read: if true;
      allow write: if request.auth != null
                   && request.auth.uid == resource.data.authorId;
    }
  }
}

As the Firestore Security Rules reference explains, rules are evaluated on every database operation. There's no way to bypass them from client-side code.

The mistakes that get people

Using wildcards too broadly

// DANGEROUS: allows everything under /data
match /data/{document=**} {
  allow read, write: if request.auth != null;
}

This lets any authenticated user read and write every document in the data collection and all subcollections. A logged-in user can access every other user's data.

Only checking authentication, not authorization

// BAD: any logged-in user can read any order
match /orders/{orderId} {
  allow read: if request.auth != null;
}

Authentication means "this person has an account." Authorization means "this person is allowed to access THIS specific resource." You need both.

Not validating writes

// BAD: user can write anything to their profile
match /users/{userId} {
  allow write: if request.auth.uid == userId;
}

This lets users set their own role to admin, change their email to someone else's, or add arbitrary fields. Validate the data being written:

match /users/{userId} {
  allow update: if request.auth.uid == userId
                && request.resource.data.keys().hasOnly(['name', 'bio', 'avatar'])
                && request.resource.data.name is string
                && request.resource.data.name.size() <= 100;
}

Forgetting about Cloud Storage

Firestore rules and Storage rules are separate. Even if your Firestore is locked down, your Storage buckets might be wide open. Check both.

Testing your rules

Firebase provides the Rules Playground in the Firebase Console and a local emulator for testing rules. Use them. Write rules, test with different auth states and data, and verify that unauthorized access is denied.

Test these scenarios:

• Unauthenticated user reads data
• Authenticated user reads another user's data
• User writes invalid data
• User tries to escalate their role

The bottom line

Firebase API keys are public. Your project ID is public. Your database URL is public. Security Rules are literally the only thing between your data and anyone on the internet. Treat them like production code, not an afterthought.

Check your site

Want to know if your site has this issue? Scan it now and find out in 60 seconds.