IS FIREBASE SAFE? SECURITY ANALYSIS | VIBEEVAL

Security Rules are Critical

Firebase Security Rules are the only barrier between your data and the public internet. Unlike traditional databases behind a server, Firebase is directly accessible from clients. Misconfigured rules expose all your data. The Firebase config in your bundle includes the API key and project ID by design — they are not secrets, they are identifiers. The secret is your rules logic.

The pattern we see most often: an AI generator scaffolds a Firebase app, writes Firestore reads against users/{userId}, and never publishes a firestore.rules file. The default rules from the console — set to “test mode” with a 30-day timer — silently expire to deny-all, the app breaks, the developer pastes allow read, write: if true; into the rules and ships. Now everyone can read everyone’s data forever.

Common Security Issues

Open Security Rules

Many apps launch with rules that allow all reads and writes. This is the default for development but catastrophic in production:

// DANGEROUS - default test mode after expiry
match /{document=**} {
  allow read, write: if true;
}

The {document=**} recursive wildcard means every collection, every document, every subcollection. The whole project is public.

Rule Logic Errors

Complex Security Rules syntax leads to logical errors that create unintended access paths. The most common mistakes:

// BAD: only checks user is logged in, not whose data
match /users/{userId} {
  allow read: if request.auth != null;
}

// GOOD: scope to the requesting user
match /users/{userId} {
  allow read: if request.auth != null
              && request.auth.uid == userId;
}

Equally dangerous: allow write: if request.auth.uid == request.resource.data.owner — the user can write any value to owner, including their own UID, and immediately own the document.

Rule Evaluation Order

Firestore evaluates allow rules with OR semantics across match blocks. A permissive rule on a parent path overrides a stricter rule on a child:

// Outer rule grants read; inner rule cannot revoke it
match /posts/{post} {
  allow read: if true;
  match /comments/{c} {
    allow read: if request.auth != null;  // useless
  }
}

Always write rules tightest at the root and only widen explicitly.

Exposed Configuration

Firebase config in client code reveals project details. While normal, it emphasizes the need for proper Security Rules. The danger is not the config — it is the developer who hides the config thinking it adds security, then writes loose rules because “the API key is hidden anyway”.

Missing Validation

Security Rules should validate data structure and content, but this is often skipped. A rule like allow create: if request.auth.uid == request.resource.data.owner lets the user write any other field — including isAdmin: true if your app reads admin status from Firestore. Validate the shape:

allow create: if request.auth.uid == request.resource.data.owner
              && !('isAdmin' in request.resource.data)
              && request.resource.data.keys().hasOnly(['owner', 'title', 'body']);

Storage Rules Forgotten

Firestore rules and Storage rules are separate files and separate deploys. Locking down Firestore does nothing for Storage. Storage’s default test-mode rule is just as open as Firestore’s, and AI generators forget the Storage file constantly.

// In storage.rules
match /uploads/{userId}/{file} {
  allow read, write: if request.auth.uid == userId;
}

Realtime Database Cascading Rules

Realtime Database rules inherit downward — a .read: true at the root grants read on every node below. Many apps set a permissive root rule “for now” and forget. Audit database.rules.json from the root down, not from the leaves up.

Security Assessment

Strengths

• • Google-grade infrastructure security
• • Built-in authentication with multiple providers
• • Security Rules provide granular access control
• • Automatic HTTPS and TLS encryption
• • SOC 2, ISO 27001 compliance
• • App Check protects against abuse from non-app clients
• • Firebase Emulator Suite for offline rule testing

Concerns

• • Security Rules often misconfigured or disabled
• • Default rules may allow public read/write
• • Client-side SDK exposes configuration
• • Complex rule syntax leads to errors
• • No RLS - relies entirely on Security Rules
• • Storage and Firestore rules are separate, easy to forget one
• • Cloud Functions with Admin SDK bypass all rules
• • Realtime Database rules cascade in surprising ways

Firebase vs Supabase: rule model comparison

Firebase and Supabase solve the same problem — direct client access to a database — with different rule languages.

• Firebase Security Rules are a path-based DSL with match blocks. Compact for per-document access. Powerful with get() and exists() for cross-document checks, though those count as billable reads.
• Supabase RLS uses Postgres CREATE POLICY statements. Full SQL expressiveness — joins, subqueries, custom functions. Per-table, not per-row-path.

Both default to deny-all once enabled. Both can be defeated by an over-permissive rule. The most common mistake is identical: a rule that checks “is the user logged in” instead of “is this row owned by the logged-in user”.

The Verdict

Firebase is safe as a platform with Google’s security backing. However, the security of your Firebase application depends entirely on your Security Rules configuration. Test rules thoroughly using the Firebase Emulator and Rules Playground before deployment. Never deploy with default open rules.

Four checks before production:

1. firestore.rules and storage.rules are both committed to source control and deployed.
2. No match /{document=**} { allow read, write: if true; } block exists anywhere.
3. Every allow rule that touches user data references request.auth.uid and compares it to a field in the document.
4. App Check is enabled on production, blocking calls that don’t come from your verified app.

Related Resources

How to Secure Firebase

Step-by-step security guide covering rule patterns, App Check, and Cloud Functions hardening.

Firebase Security Checklist

Interactive security checklist with the rule snippets you can paste in.

Firebase Studio Security Scanner

Run a full security scan against your live Firebase project that probes every collection for rule bypass.

Token Leak Checker

Find Firebase Admin SDK keys or service account JSONs that shipped to a public surface.

Scan Your Firebase App

Let VibeEval check your Firebase application for security vulnerabilities. The scanner exercises both Firestore and Storage rules, attempts cross-tenant reads, and reports anything that came back when it shouldn’t have.