Firebase Rules: Why Setting Read/Write to True Is a Disaster

There's a single curl command that can delete your entire Firebase database. If your rules still say "write": true, anyone can run it.

Every Firebase tutorial starts the same way. You create a project, set up Realtime Database or Firestore, and the quickstart guide tells you to use these rules for development:

// Realtime Database — the "just get it working" rules
{
  "rules": {
    ".read": true,
    ".write": true
  }
}

// Firestore — the "test mode" rules
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

Then you forget about it. Your app works, you ship it, and your entire database is now a public API that anyone on the internet can read and write to.

What an Attacker Can Do

Your Firebase project ID is public. It's in your client-side JavaScript. With open rules, anyone can do this:

# Read your entire Realtime Database
curl https://YOUR-PROJECT.firebaseio.com/.json

# Read every user's data
curl https://YOUR-PROJECT.firebaseio.com/users.json

# Write whatever they want
curl -X PUT -d '{"hacked": true}'   https://YOUR-PROJECT.firebaseio.com/users/admin.json

# Delete everything
curl -X DELETE https://YOUR-PROJECT.firebaseio.com/.json

Firestore Is the Same Problem

Firestore's "test mode" rules expire after 30 days, but Firebase sends you an email warning and many developers just extend the date or switch to allow read, write: if true to make the warning go away. Same result: everything's public.

Not sure if your rules are open? vibeAudit checks Firebase rules automatically — 30 seconds, free. Using Supabase instead? Check our RLS guide.

How to Fix It: Common Patterns

Pattern 1: User-owned data (most common)

Each user can only read and write their own data. This covers profiles, settings, saved items.

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

// Realtime Database equivalent
{
  "rules": {
    "users": {
      "$uid": {
        ".read": "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

Pattern 2: Public read, private write

Good for blogs, product listings, public content. Anyone can read, only authenticated owners can write.

// Firestore
match /posts/{postId} {
  allow read: if true;
  allow write: if request.auth != null
    && request.auth.uid == resource.data.authorId;
}

Pattern 3: Admin-only access

For dashboards, settings, or anything that only admins should touch. Use custom claims.

// Firestore: only users with admin custom claim
match /admin/{document=**} {
  allow read, write: if request.auth != null
    && request.auth.token.admin == true;
}

// Set admin claim server-side (Node.js Admin SDK):
const admin = require('firebase-admin')
await admin.auth().setCustomUserClaims(uid, { admin: true })

How to Check If You're Exposed Right Now

Takes 10 seconds. Open a terminal and run:

# Replace YOUR-PROJECT with your Firebase project ID
curl https://YOUR-PROJECT.firebaseio.com/.json

# If you get back actual data instead of "Permission denied",
# your database is wide open.

For Firestore, check the Rules tab in your Firebase Console. If you see allow read, write: if true anywhere, fix it now.

FAQ

Q: Can someone delete my entire Firebase database?

If your rules are set to read/write: true, yes. A single curl command with your project ID is enough.

Q: Are Firebase test mode rules safe for production?

No. Test mode rules give everyone full read and write access. Replace them with user-specific rules before going live.

Your Firebase project ID is already public. Are your rules open too? Paste your URL into vibeAudit and find out — 30 seconds, free. Read-only scan, your app is never modified.