Is Firebase Safe? Security Analysis

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.

That path is not hypothetical. It is the modal Firebase finding in AI-built apps: the demo needed open rules, production inherited them, and App Check / Auth were assumed to “cover it” without ever being wired into the rules expressions.

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.

Slightly less obvious variants still fail:

// Still open to the world after the date
allow read, write: if request.time < timestamp.date(2030, 1, 1);

// "Logged in" only - any account reads any user
allow read, write: if request.auth != null;

Ship deny-by-default, then open known paths with ownership checks. Never keep a catch-all if true “for debugging” in the same file as production matches.

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.

Ownership on create must bind request.resource.data.owner (or equivalent) to request.auth.uid. Ownership on update/delete must read resource.data.owner (existing doc), not only the request payload. Mixing those up is a classic privilege flip.

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. Prefer separate top-level collections with explicit matches over deep trees of “open parent, locked child” hope.

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”.

Also separate the web API key (public, in firebaseConfig) from service account JSON (admin, never in a browser). AI codegen sometimes imports firebase-admin into a client component “to create users from the form,” embedding the service account. That is a full project compromise, not a rules issue - rotate immediately and remove admin from the client graph. Use Token Leak Checker on the deployed bundle.

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']);

Cap string lengths, enforce types (is string, is number), and reject unknown keys. Rules are your last schema check when clients write directly.

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
    && request.resource.size < 5 * 1024 * 1024
    && request.resource.contentType.matches('image/.*');
}

Also decide which paths are truly public (marketing images) vs private (IDs, invoices). Do not mix them under one open prefix. Strip EXIF if avatars can leak location; that is app logic, but Storage rules at least stop anonymous listing of private prefixes.

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.

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

Cloud Functions as Admin SDK bypass

Any Cloud Function using the Admin SDK bypasses Security Rules. That is correct for privileged jobs - dangerous when the function is just a proxy for client input:

// BAD - path from user, admin read
exports.getDoc = functions.https.onCall(async (data, context) => {
  if (!context.auth) throw new functions.https.HttpsError("unauthenticated", "login");
  return admin.firestore().doc(data.path).get().then((s) => s.data());
});

// BETTER - fixed collection, ownership check, least fields
exports.getMyProfile = functions.https.onCall(async (_data, context) => {
  if (!context.auth) throw new functions.https.HttpsError("unauthenticated", "login");
  const uid = context.auth.uid;
  const snap = await admin.firestore().doc(`users/${uid}`).get();
  return snap.data();
});

Callable and HTTPS functions also need abuse controls: App Check, rate limits, payload size limits, and never reflecting stack traces. A Function that “lists all users for the admin dashboard” without verifying a custom claim is an open directory.

App Check skipped

App Check reduces abuse from scripts that are not your real app. It is not authorization - a determined attacker can still call with a real app install - but it stops anonymous bulk scraping with curl. Enable App Check on Firestore, Storage, and Functions for production.

Wire enforcement gradually: monitor mode first, then enforce, so legitimate clients with broken attestation do not brick production without a signal.

Auth token claims you forget to check

Firebase Auth issues ID tokens with claims. Rules can read request.auth.token.email_verified, custom claims (admin), and sign-in provider. High-trust actions should require verification:

allow update: if request.auth != null
  && request.auth.token.email_verified == true
  && request.auth.uid == userId;

Without that, a throwaway account with an unowned email can still pass request.auth != null checks. Combine with rate limits on account creation for consumer apps.

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
• • Custom claims for server-set roles

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
• • AI scaffolds optimize for “it works” over “it is locked”

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”.

See Is Supabase Safe? for the Postgres-side twin of this guide.

Multi-tenant patterns that fail in Firebase

SaaS apps often model orgs as orgs/{orgId}/... with membership documents. Failure modes:

• Rules check request.auth != null but not membership in the org.
• Membership docs are client-writable (allow write: if request.auth.uid == userId on members/{userId}), so anyone can add themselves to any org.
• Cross-document get() checks exist but omit null/missing membership denial.
• List queries on org collections allowed without a constraint rules can prove.

Safer pattern: set org membership via Cloud Functions (Admin SDK) after invite acceptance; rules only read membership with exists() / get() and deny client writes to membership paths.

function isOrgMember(orgId) {
  return request.auth != null
    && exists(/databases/$(database)/documents/orgs/$(orgId)/members/$(request.auth.uid));
}

match /orgs/{orgId}/projects/{projectId} {
  allow read: if isOrgMember(orgId);
  allow write: if isOrgMember(orgId)
    && request.resource.data.keys().hasOnly(['name', 'updatedAt', 'ownerUid']);
}

How to verify rules before launch

1. Unit tests with @firebase/rules-unit-testing - assert allow/deny for owner, other user, and unauthenticated.
2. Rules Playground in the Firebase console for quick ad-hoc checks (not a substitute for tests).
3. Live probe: from an anonymous client, try getDoc / list on every collection path your app uses.
4. Cross-tenant: authenticated as user B, request user A’s document by ID.
5. Storage: attempt download of another user’s path.
6. Functions: call every HTTPS/callable with missing auth and with another user’s IDs.
7. Run Firebase Scanner / VibeEval against the deployed app.

// rules-unit-testing sketch
import { assertFails, assertSucceeds } from "@firebase/rules-unit-testing";

await assertFails(unauth.firestore().doc("users/alice").get());
await assertSucceeds(alice.firestore().doc("users/alice").get());
await assertFails(bob.firestore().doc("users/alice").get());

Expand tests when you add collections - AI feature work is the usual regression moment. A CI job that boots the emulator and runs the rules suite on every PR is cheap insurance.

Common mistakes in AI-generated Firebase apps

• Shipping console test mode rules past the expiry date.
• request.auth != null without UID ownership.
• Admin flags writable by clients (isAdmin in document fields).
• Storage still open while Firestore looks locked.
• Service account JSON committed or embedded in a web bundle.
• Callable functions that accept arbitrary collection paths.
• No email_verified check for high-trust actions.
• Relying on hiding the config instead of rules.
• Using Realtime Database with a root .read: true “for the chat demo.”
• Client SDK list queries that dump entire collections once any doc is readable.
• Custom claims never set, roles stored in editable user docs.

Cost and abuse angles (not only data leaks)

Open rules are not only a confidentiality problem. Attackers can:

• Write huge documents until you hit storage bills.
• Create millions of auth users against projects without App Check.
• Trigger Functions with spam callables.
• Host malware files on open Storage and abuse your domain reputation.

App Check + rules + quotas + billing alerts belong on the same launch checklist as ownership checks.

Pre-launch checklist (10 minutes)

1. firestore.rules and storage.rules committed and deployed.
2. No match /{document=**} { allow read, write: if true; } anywhere.
3. Every user-data path compares request.auth.uid to the resource owner.
4. Creates/updates validate keys and forbid privilege fields.
5. App Check enabled on production.
6. No service account material in the client bundle (Token Leak Checker).
7. Functions re-check auth and never trust client-supplied paths for admin reads.
8. Emulator tests for owner / stranger / anon on each collection.
9. Dynamic scan on the live URL.
10. Billing alerts on for unexpected write/read spikes.

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.

Add a fifth if you use Cloud Functions: no Admin SDK path constructed from raw client input.

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.

Firebase Security Rules: common mistakes

Full guide to rule patterns that fail in production.

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.