Firebase security: what Google handles, and where your app still leaks

Is Firebase secure?

The platform is a solid base, and most Firebase leaks are not Firebase bugs. Google runs the servers, checks every request your app sends to Firestore, the Realtime Database and Storage against rules you deploy, and since May 2024 restricts every API key it provisions to Firebase services. What it cannot do is decide who should read your data. Firebase's own documentation says it plainly: the API key in your app only identifies your project, and authorization comes from Google Cloud IAM, Firebase Security Rules and App Check. Two of those three are things you write or switch on.

An app built on it is as tight as its rules, its Auth settings and the code of its Cloud Functions. Your web config, API key included, sits in your JavaScript for anyone to read, as Firebase intends. The rules behind it are what a stranger really tests.

What Firebase is responsible for, and what you are

Firebase's security checklist and product docs draw the line clearly: Google provides the enforcement and the safe defaults, and deciding what each user may do is your part.

The Firebase stack, and where apps built on it leak

A Firebase app is a frontend that talks straight to Google's services through the SDK, plus optional server code. Here is what you find in one, and the weak spot of each part.

• Cloud Firestore, a document database guarded by Security Rules. It leaks through rules that allow everyone, any signed-in user, or a catch-all wildcard. The Firebase security rules guide takes these patterns one by one.
• Realtime Database, one large JSON tree with rules written in JSON. A rule on a parent path applies to everything below it, so one ".read": true near the root opens the whole tree.
• Cloud Storage for Firebase, files in a bucket with their own rules file. It leaks when receipts, ID scans or private photos sit under a rule that lets anyone list or read them.
• Firebase Authentication. The sign-up endpoint only needs your public API key, and anonymous sign-in, when enabled, does not even ask for an email. Rules that only check request.auth != null therefore let any stranger in after one request.
• Cloud Functions and App Hosting, your server code. The server libraries skip Security Rules entirely, so each function decides on its own who may do what. HTTP functions (onRequest) do not validate tokens for you, unlike callable functions (onCall).
• Firebase SQL Connect, called Data Connect until recently: PostgreSQL on Cloud SQL behind GraphQL operations. Each operation needs an @auth directive. PUBLIC lets anyone run it, and USER alone accepts any signed-in user unless a filter ties the rows to them.
• Other Google API keys. A Maps or Gemini key can live in the same Google Cloud project as your Firebase key. A key that reaches the Gemini API, or one left unrestricted, turns into a bill anyone can run up.

Apps built by AI coding agents follow the same shape, with one habit that makes it worse: when a screen throws a permission error, the agent writes whatever rule makes it work, and that is often the widest one. Google's own AI builder, Firebase Studio, no longer creates new workspaces and shuts down on 22 March 2027, with Google pointing its users to Google AI Studio and Antigravity. Only the development environment goes away: the Firestore data, Auth users and deployed rules of those projects keep running, open or not.

What a stranger can do with a misconfigured Firebase app

Everything below starts from what any visitor already has: your web config, read from your JavaScript. Each row is a known mistake in an app, not a flaw in Firebase.

The Gemini row is the newest. Firebase's API key page now says never to include the Gemini Developer API in the allowlist of a public key, and to keep the Gemini key out of your code and config files entirely. Truffle Security showed why: a Google key created for Maps or another service and left unrestricted becomes a Gemini credential the day someone enables that API on the project. Scanning the November 2025 Common Crawl archive, they found 2,863 live Google API keys on public web pages that the Gemini API accepted. Their disclosure timeline says Google then began blocking the leaked keys it finds from calling Gemini, which helps but does not restrict your keys for you. The unprotected AI endpoint guide covers the same risk on your own routes.

What Firebase's own tools catch, and what they miss

Firebase gives you more help than it used to, and some of it is very good:

• Safe starting modes. Firestore's production mode and the Realtime Database's locked mode deny all client access until you write rules. The security checklist tells you to start there and to write each rule before the feature that needs it, like a schema.
• Rules Playground and the Emulator Suite. The Playground in the console simulates one request against your rules and says allowed or denied. The Local Emulator Suite runs rules unit tests, which Firebase recommends adding to CI.
• The Firebase MCP server. It gives coding agents firebase_get_security_rules to read the live rules, firebase_validate_security_rules to check them for errors, and prompts that generate Firestore and Storage rules with unit tests.
• App Check. It rejects requests that do not come from your registered app on a genuine device, using reCAPTCHA Enterprise on the web, Play Integrity on Android, and App Attest or DeviceCheck on Apple platforms. From 2 November 2026, Firebase turns on App Check enforcement for Firebase AI Logic in every project where it is not already on, unless you asked for a temporary delay.

Each tool answers a narrower question than "can a stranger read my data":

• The MCP validation checks syntax and errors. allow read: if true is perfectly valid.
• The Playground and the emulator test the requests you think of. A collection you forgot, or user B reading user A's document, is tested only if you write that test.
• App Check is not a lock on your data. Firebase's page says it prevents some, but not all, abuse. A stranger using your real website in a real browser still passes it, and so does anyone who signs up. On Cloud Functions, it covers callable functions only.
• None of them read your Cloud Functions code, the Google keys in your bundle, or what your Auth settings let a stranger do.

How to check your Firebase app

Six checks on your own project, in this order. None of them changes anything.

1. Read the rules that are live

In the Firebase console, open the Rules tab of Firestore Database, Realtime Database and Storage, or ask your agent to fetch them with firebase_get_security_rules. Look for if true, a request.time < date, request.auth != null with no uid comparison, a recursive wildcard that matches every document from the top level, and ".read": true near the root of the Realtime Database. The Firebase rules checker reviews them line by line.

2. Ask your own database as a stranger

These requests use the public values from your Firebase config (project ID, web API key, database URL, bucket) and no account. Run them against your own project only.

curl "https://firestore.googleapis.com/v1/projects/YOUR_PROJECT_ID/databases/(default)/documents/users?pageSize=1&key=YOUR_WEB_API_KEY"

curl "YOUR_DATABASE_URL/.json?shallow=true"

curl "https://firebasestorage.googleapis.com/v0/b/YOUR_BUCKET/o"

A document, a list of keys or a list of files in the answer means anyone can get them. A permission denied error (HTTP 401 or 403) means the rules refused, which is what you want for private data. An empty answer from Firestore means the collection is empty or does not exist, so try one you know has data.

3. Replay it as a second user

In the Rules Playground, simulate a read of a real document path while signed out, then signed in with a uid that is not the owner's. Both should be denied. Turn the cases that matter into emulator unit tests, so the next rules change gets checked too. This is the database version of an IDOR vulnerability, and the most common access bug we see in generated apps.

4. Audit your Google API keys

In the Google Cloud console, open APIs & Services, then Credentials. A warning icon next to a key means it is unrestricted. A key that lists the Generative Language API (the Gemini API) must never appear in client code. Then search your built JavaScript for strings starting with AIza: the Firebase config key belongs there, and so can a Maps key restricted to your domain and to the Maps APIs. Any other Google key is a leak. The API key leak checker runs that search on a pasted bundle.

5. Review Auth

Under Authentication, list the enabled sign-in methods. If anonymous sign-in is on, every rule on private data has to tell anonymous users apart. Check that email enumeration protection is on, under Security, then Authentication, then the Settings tab: projects created before 15 September 2023 do not have it by default.

6. Read your functions

In functions/, list every onRequest export. Each one must check the caller's Firebase ID token and their right to the data before it touches anything, because the Admin SDK it uses skips your rules. Callable functions validate the token for you, but your code still has to check that request.auth exists and owns what it asks for.

Fixes, with prompts for your coding agent

Each fix comes with a prompt to paste into Cursor, Claude Code or whichever agent built the app. Read the diff before you deploy: an agent told to "fix the rules" can close everything and break the app, or open more to make an error go away.

Rules: deny by default, then one rule per collection and action

The rule agents write most often is a recursive wildcard that matches every document with allow read, write: if request.auth != null;. It lets any account, anonymous ones included, read and write everything. Replace the whole file with one that denies by default and states who may do what on each collection:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Each user reads and edits their own profile, and cannot change their role
    match /users/{userId} {
      allow read: if request.auth != null && request.auth.uid == userId;
      allow create: if request.auth != null && request.auth.uid == userId
        && !('role' in request.resource.data);
      allow update: if request.auth != null && request.auth.uid == userId
        && !request.resource.data.diff(resource.data).affectedKeys().hasAny(['role']);
    }
  }
}

Rewrite firestore.rules, database.rules.json and storage.rules so that everything is denied by default. Then add one rule per collection or path the app uses, stating who can read, create, update and delete, tied to request.auth.uid and the owner field stored in the document. Users must not be able to change role, plan, price or owner fields. Write emulator unit tests that try each path signed out and as a second user, and run them before deploying.

Auth: decide who can get an account

If the app is invite-only, an open sign-up endpoint is a gift to strangers. A blocking function (beforeUserCreated) can refuse accounts that do not match your rules, for example an email domain. Blocking functions require upgrading the project to Firebase Authentication with Identity Platform. If you keep anonymous sign-in, protect every non-public path with a rule that rejects anonymous users or unverified emails, following Firebase's checklist:

// Option 1: refuse anonymous accounts
allow write: if request.auth != null
  && request.auth.token.firebase.sign_in_provider != "anonymous";

// Option 2: require a verified email
allow write: if request.auth != null
  && request.auth.token.email_verified == true;

On older projects, turn on email enumeration protection. If you use email and password sign-in, Firebase also recommends tightening the default quota of the identitytoolkit.googleapis.com endpoints, on the Identity Toolkit API page of the Google Cloud console, to slow down brute force attempts.

Keys: one key per job, each restricted

Leave the Firebase config key where it is: it is meant to be public. Check that it is still restricted to Firebase APIs (someone may have added others), give Maps its own restricted key, and never ship a key that reaches the Gemini API. Call Gemini from a server, or through Firebase AI Logic with App Check enforced. If a Gemini-capable key ever reached your bundle, treat it as leaked and follow what to do when an API key leaks. The Firebase API key guide goes deeper on the config key itself.

Find every Google API key (strings starting with AIza) in this repo and in the built bundle. Keep only the Firebase web config key on the client. Move every Gemini call to a callable Cloud Function that checks request.auth and reads its key from Secret Manager, or switch it to Firebase AI Logic with App Check. List the keys I must restrict or rotate in the Google Cloud console, and why.

Functions: check the caller every time

import { onCall, HttpsError } from "firebase-functions/https";
import { initializeApp } from "firebase-admin/app";
import { getFirestore } from "firebase-admin/firestore";

initializeApp();

export const deleteNote = onCall({ enforceAppCheck: true }, async (request) => {
  if (!request.auth) throw new HttpsError("unauthenticated", "Sign in first.");
  const ref = getFirestore().collection("notes").doc(String(request.data.noteId));
  const note = await ref.get();
  if (note.get("ownerId") !== request.auth.uid) {
    throw new HttpsError("permission-denied", "Not your note.");
  }
  await ref.delete();
  return { deleted: true };
});

Keep third-party keys such as Stripe or OpenAI in Cloud Secret Manager, which Firebase's checklist recommends for the credentials your Cloud Functions need and which App Hosting uses for its secrets. Cap the number of instances of costly functions, and set budget alerts so a flood of calls shows up before the invoice does.

List every Cloud Function in functions/. For each onRequest function, add a check of the Firebase ID token and of the caller's right to the data it touches, or convert it to onCall. For each onCall function, check request.auth and ownership before any read or write, and set enforceAppCheck: true. Move any secret found in code or .env files into Secret Manager.

The traps after the first fix

• The console and the repo disagree. Firebase's docs warn that rules deployed with the Firebase CLI overwrite the rules in the console. If you edit rules in the console and also keep firestore.rules in the repo, the next firebase deploy publishes the file. Make the file the only source of truth.
• Storage has its own rules. Locking Firestore does nothing for the bucket. Storage rules can read Firestore with firestore.get() and firestore.exists(), which helps when access to a file depends on a document.
• Your server is a second door. Code using the Admin SDK in Cloud Functions, App Hosting or any other server skips Security Rules. An API route that returns Firestore data to whoever asks undoes every rule. Sign in as user B and ask for user A's records.
• Keys you made yourself keep their settings. Firebase restricted the keys it provisioned in May 2024, but a key created in the Google Cloud console, for Maps for example, can call every API enabled on the project unless someone restricted it. Projects created before 15 September 2023 also have no email enumeration protection unless someone turned it on.
• Secrets inside documents. A config collection holding a Stripe or OpenAI key is readable by whoever your rules let in. Keys belong in Secret Manager, never in data a client can read.
• The test mode date. A rule that allows everything until a date leaves the data open until then and breaks the app after. Replace it with real rules instead of pushing the date back.
• App Check registered, not enforced. App Check rejects requests only once you turn on enforcement for that product. Until then, it blocks nothing.

Test the live app, not only the rules file

The rules file, the Playground and a checklist tell you what you meant. A stranger only cares about what the live app answers. On an app whose owner proved ownership, Keybrum attacks Firebase the way a visitor would:

• it takes the Firebase config and the collection names from your JavaScript, minified code included, and adds common names such as users, orders and messages;
• it reads each Firestore collection with no account, then again as a brand-new account it signs up itself;
• it tests writes with a request that can never create anything: rules are checked first, so the answer proves whether the write was allowed, and nothing is stored;
• it reads the root of the Realtime Database and lists the Storage bucket, flagging receipts and identity documents;
• it looks for API keys in the documents it could read and in your bundle, and checks with a free read-only call whether a Google key can reach Gemini;
• it goes past Firebase: data across two accounts, unprotected AI endpoints, exposed .env files and security headers.

Each finding comes with the request that worked. Your coding agent reads the findings and the fixes through Keybrum's MCP server, and Keybrum attacks again after the fix and, on a plan, on every deploy.

Firebase security checklist

• Firestore, the Realtime Database and Storage start from deny-all, with one rule per collection or path.
• No if true, no test mode date and no request.auth != null alone on private data.
• Every owner check compares request.auth.uid with a uid stored in the document or in the path.
• Write rules block changes to role, plan, price and owner fields.
• Write rules check the type and size of each field users can set, for example request.resource.data.title is string && request.resource.data.title.size() <= 200.
• Rules live in the repo, are tested in the emulator as a stranger and as a second user, and are deployed from there.
• Anonymous users and unverified emails cannot reach private data.
• Email enumeration protection is on, and the sign-in quota is tightened.
• If the app is invite-only, a blocking function filters sign-ups.
• The Firebase config key is still restricted to Firebase APIs, and any other key in the client is restricted to its own API and your domain.
• No public key reaches the Gemini API: Gemini runs on a server or through Firebase AI Logic.
• App Check is enforced on Firestore, the Realtime Database, Storage, callable functions and AI Logic.
• Every Cloud Function checks the caller and their right to the data.
• Service account keys, FCM server keys and third-party secrets live in Secret Manager, never in the bundle or in Firestore.
• Budget alerts, spend caps and function instance limits are set.
• Development, staging and production are separate Firebase projects.

The vibe coding security checklist puts these next to the rest of a launch review, and the security risks of vibe coding explains why generated apps keep hitting the same holes.