CriticalData access

Firebase rules left in test mode

Anyone with the app's public Firebase config, which sits in its JavaScript, can read, overwrite or delete the entire database and storage bucket without signing in. Rules that decide which user can read or change which rows in the database. Check it yourself with the steps below; our test adds what a script and a second account can find.

What it looks like

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

The open ruleset Firebase offers for getting started, which allows anyone to read and write every document, still deployed on a live app.

What happens

Anyone with the app's public Firebase config, which sits in its JavaScript, can read, overwrite or delete the entire database and storage bucket without signing in.

Where it shows up

Descriptive, not a verdict: builders and stacks whose defaults make this reachable, or that a public incident names. Each hub states the tool's own security features.

Check it yourself

Uses your builder's dashboard and your browser. No tools to install.

Open the Firebase console, choose your project, then Firestore Database (or Realtime Database, or Storage) and open the Rules tab.
Read the rules. Look for allow read, write: if true, ".read": true, ".write": true, or a rule that checks only request.auth != null on private data.
Check the top of the Firebase console for a banner about insecure or expiring rules; Firebase shows one when it detects open rules.
A bad result is any if true rule on a live project, or a banner warning about your rules.

What we check

We take the public Firebase config from the deployed app and, without signing in, try to list, read, write and delete documents in each collection and files in each bucket. We then repeat the run as two ordinary accounts. The report shows each collection, the rule text and the operations that succeeded.

Fix direction

Rewrite the rules so each collection allows access only to its owner or role, using request.auth.uid against an owner field, and deny everything else, which is what Firebase's locked mode does from the start. Test the new rules against several users in the Firebase emulator before deploying.

Mechanism documented in: Basic Security Rules (verified 2026-09-21); Avoid insecure rules (verified 2026-09-21).

Covered by

Pre-launch check ($490, 48 hours) and Security sweep ($290, 24 hours)

Both include a re-check after your fixes.

Compare packages

Related patterns

Row Level Security disabled on a tableData access
Anyone with the project URL and the public anon key, both of which sit in the app's JavaScript, can read, edit or delete every row in the table.
Critical
Any signed-in user can read every rowData access
Anyone who creates a free account can page through every other customer's records, which is a data breach with a sign-up form as the only step.
Critical
Uploaded files in a public storage bucketData access
Anyone who has or guesses a file link can download customer uploads such as ID scans, contracts or invoices, with no login.
High
Record ids accepted without an ownership checkData access
Anyone who changes the id in a URL or request can read, edit or delete another customer's record.
Critical

Questions

what is the difference between firebase test mode and locked mode

When you create a Firestore, Realtime Database or Storage instance, Firebase offers two starting rulesets. Locked mode denies access to all users until you write rules. Test mode allows anyone access, which Firebase documents as a development setting to change before an app goes to production. Firebase notes that its Security Rules are the only safeguard between clients and your data.

how do i check my firebase security rules

In the Firebase console, open Firestore Database, Realtime Database or Storage and click the Rules tab. Rules that say allow read, write: if true or .read: true open the data to everyone. Firebase's guide to insecure rules also flags rules that check only that a user is signed in, since every account then sees every document.

is firebase config in frontend code a security risk

The Firebase web config (apiKey, projectId and so on) is designed to be public and identifies your project rather than granting access. Access is controlled by your Security Rules, which is why open rules matter: anyone with the config can call your database directly. Rules that check ownership per document are what keeps the public config harmless.

Back to the catalogue, or run the self-check for your stack.