Firebase Security for AI-Built Apps: The Complete Guide

You asked an AI builder for a backend, it wired up Firebase, and your app works. Now you've found your Firebase config sitting right there in your frontend code — the apiKey, the project ID, all of it — and your stomach dropped. Did you leak the keys to your whole app?

Here's the reassuring part, and it's the first thing every Firebase guide should say: that config is supposed to be public. It's an address label, not a password. What actually keeps your data safe is your Firebase Security Rules — and most of that you can check and fix yourself.

This is the hub for everything about Firebase security on AI-built apps. We'll cover what's public versus secret, the three controls that do the real work — Security Rules, locked Storage, and App Check — and the one key that truly ends your week if it leaks. Then we'll point you to deeper guides for each risk area.

⚡ TL;DR

• Your Firebase web config / apiKey is public by design. It identifies your project; it does not grant access. Do not panic about it and do not rotate it.
• Real protection comes from three things: Security Rules (who can read/write your database), locked Storage rules (who can read/write your files), and App Check (proving requests come from your real app).
• The one secret you must never ship is the service-account key — the server-side admin credential that bypasses every rule.

What Firebase actually is (and why AI builders reach for it)

Firebase is Google's backend-as-a-service. Instead of writing and hosting your own server, you get a hosted database (Firestore or Realtime Database), file storage, user authentication, and hosting — all reachable from a few lines of JavaScript in the browser.

That's exactly why some AI builders pick it. When you say "let users sign up and save their data," Firebase lets the tool ship a working app with no backend server to stand up, no API to write. The browser talks straight to Google's services.

And that last part is the whole security story. Because there's usually no backend server in the middle checking "is this person allowed to do this?", the checking has to happen somewhere else. In Firebase, that somewhere is Security Rules — a small rulebook that lives on Google's side and runs on every single request. Get the rules right and your app is safe even though the config is public. Get them wrong and your data is open to anyone, even though nothing was technically "hacked."

Most vibe-coded backends are Supabase, not Firebase — Supabase is the default for Lovable, Bolt, v0, Replit, and Cursor templates. But Firebase shows up often enough (and in some of the largest breaches) that if it's your backend, the rules below are the most important thing you'll read this week.

The myth to kill first: the apiKey is not a secret

Let's defuse the alarm that brings most people here, because it sends founders chasing the wrong fix.

A typical Firebase web config looks like this, and yes, it ships in your frontend where anyone can read it:

const firebaseConfig = {
  apiKey: "AIzaSyD-EXAMPLE-not-a-secret",
  authDomain: "your-app.firebaseapp.com",
  projectId: "your-app",
  storageBucket: "your-app.appspot.com",
  appId: "1:1234567890:web:abc123"
};

It looks like a wall of secrets. It isn't. The Firebase apiKey is an identifier, not an authorizer. It tells Google "these requests are for the project called your-app." It does not, on its own, grant permission to read or write anything. That's a job Security Rules do, separately.

🐺 Not a real problem

An exposed Firebase web config / apiKey is not a leak. Google designed it to be public and embedded in your frontend. If a scanner told you to rotate it, that scanner is crying wolf. The real question is always: do your Security Rules and Storage rules actually restrict who can read and write?

There is one Firebase credential that is a true secret, and confusing it with the web key is where people get hurt. We come back to it below. For the full breakdown of what's public versus what's secret, see your Firebase web config is public by design.

Firebase Security Rules and the two controls beside them

If the key isn't the lock, what is? Three things. Together they are your real security, and an AI builder tends to set up exactly none of them correctly by default.

1. Security Rules — who can read and write your database

Firebase Security Rules are the heart of Firebase security. They're a short rulebook that Google evaluates on every read and write to your Firestore or Realtime Database. They decide, request by request, whether the person is allowed to do what they're asking.

The dangerous default is a rule that allows everyone:

// DANGER: anyone on the internet can read and write everything
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

That if true means "yes to everyone, always." It's the Firebase equivalent of leaving your database with no lock at all. AI tools emit rules like this — or leave the project in test mode, which sets the same open access on a 30-day timer — because open rules make the app "work" in the preview. The hole is invisible until someone looks.

A safer rule ties each document to its owner:

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

The request.auth.uid == userId line is the part doing the work — it checks that the logged-in user owns the document. There are about a dozen ways to get this wrong, and AI builders hit most of them. We catalog them in Firebase Security Rules: 12 mistakes AI tools make.

2. Locked Storage rules — who can read and write your files

Firebase Storage (for images, uploads, documents) has its own rulebook, separate from the database. This trips people up constantly: they lock down the database, feel safe, and forget that their file bucket is wide open.

A bucket left open means anyone who knows or guesses the URL can list and download your users' files — profile photos, uploaded documents, ID images. This is not theoretical. It is the single most damaging Firebase mistake in the wild, and it's exactly how the largest breach in this space happened. We cover open buckets in depth in open Storage buckets: the #1 Firebase leak.

3. App Check — proving requests come from your real app

Even with good rules, anyone can take your public config and call your Firebase backend from a script, pretending to be your app. App Check closes that gap. It attaches a verifiable token to requests from your genuine app (web, iOS, Android) so Firebase can reject traffic from random scripts and bots.

App Check is not a replacement for Security Rules — rules decide what an authenticated user can do; App Check decides whether the request came from your app at all. You want both. AI builders almost never enable App Check, because the app works fine without it.

The one true secret: the service-account key

Here is the credential that actually deserves your fear.

A Firebase service-account key is a JSON file that grants server-side admin access through the Firebase Admin SDK. It is the master key. Code using it bypasses Security Rules entirely — read anything, write anything, delete anything, no questions asked. It's meant to live only on a server you control, never in a browser, never in a public repo.

It looks roughly like this, and if you have a file like it anywhere a user could reach it, treat that as an emergency:

{
  "type": "service_account",
  "project_id": "your-app",
  "private_key_id": "...",
  "private_key": "-----BEGIN PRIVATE KEY-----\n...REAL SECRET...\n-----END PRIVATE KEY-----\n",
  "client_email": "firebase-adminsdk@your-app.iam.gserviceaccount.com"
}

The contrast is the whole point:

• The web config / apiKey is public by design. Shipping it is fine.
• The service-account key is a real secret. Shipping it is a five-alarm fire.

A scanner that can't tell these two apart will either scare you about the harmless one or miss the dangerous one. Telling them apart is the entire job.

What this looks like when it goes wrong: the Tea app

The clearest cautionary tale is the Tea app. In July 2025, an unsecured legacy Firebase storage bucket exposed roughly 72,000 images, including about 13,000 selfies and government IDs. A second breach then exposed more than 1.1 million private direct messages. The fallout is now consolidated class-action litigation in California.

The root cause was not the public web config. Nobody "cracked the apiKey." The cause was an open Storage bucket — missing or permissive Storage rules on files that should have been locked to their owners. Every founder who reads "my apiKey is in my frontend" and panics is looking at the wrong thing; the Tea app shows where the actual danger lives. We break the incident down, soberly, in the Tea app breach.

How to check your own app

You can sanity-check a Firebase project in about ten minutes. None of this requires writing code.

1. Open the Firebase Console → Firestore (or Realtime Database) → Rules. Read the rules out loud. If you see allow read, write: if true;, or a banner saying your database is in test mode and rules expire on a date, your data is currently open to the internet.
2. Open Storage → Rules separately. This is the step people skip. Confirm your file bucket isn't allow read, write: if true; either. If your app lets users upload anything — photos, documents, IDs — this rule is the one that matters most.
3. Check whether App Check is enabled. Console → App Check. If it's off, anyone can hit your backend with your public config from a script. That's not an emergency, but it's a gap worth closing.
4. Hunt for a service-account JSON. Search your project and any public repo for "type": "service_account" and private_key. If that file is anywhere a user or the public could reach it, stop and treat it as a leak — that's the real secret.
5. Look at your app the way an attacker would. Open your app's network traffic in the browser's dev tools and watch the Firebase requests. If you can read other people's documents or files with only the public config, so can anyone else.

The fix, in order of priority

If your check turned up problems, here's the order that actually reduces risk fastest.

1. Close any if true database rules first. Replace blanket access with ownership checks (request.auth.uid == userId). This is usually the biggest, cheapest win.
2. Lock Storage rules to owners. Files default to a different rulebook; tighten it so users can only read and write their own paths. This is the lesson of the Tea app.
3. Get any service-account key out of the client and out of your repo. If one ever shipped publicly, rotate it in the Google Cloud console — that's the one Firebase credential where rotation truly matters.
4. Turn on App Check for your web and mobile apps to keep random scripts off your backend.
5. Stop rotating the web config. It's public by design; rotating it only breaks your app for no security gain.

If you build with an AI tool, you can paste a prompt like: "Review my Firestore and Storage Security Rules. Replace any allow read, write: if true or test-mode rules with rules that require authentication and check that request.auth.uid matches the document or file owner. Confirm no service-account key is present in client code. Do not change the public web config."

Firebase vs Supabase: a quick orientation

If you're choosing a backend — or trying to understand which guides apply to you — the short version is that both put the database close to the browser, so both make the rules layer the thing that matters. Supabase calls it Row Level Security (RLS); Firebase calls it Security Rules. Different names, same job: a rule the backend enforces on every query so you can't forget it. The failure modes rhyme, too: an over-flagged public key on one side, a missing or open rule on the other. We compare the two head-to-head in Firebase vs Supabase: a security comparison.

FAQ

Is the Firebase API key supposed to be public?

Yes. The Firebase web config — including the apiKey — is designed to be embedded in your frontend and visible to anyone. It identifies your project; it does not grant access. Your security comes from Security Rules, locked Storage rules, and App Check. The credential you must keep secret is the server-side service-account key.

What is the most common Firebase security mistake?

Leaving Security Rules open — either allow read, write: if true or a project left in test mode, where access is open for 30 days. The most damaging version is an open Storage bucket, because that exposes users' files (photos, documents, IDs) directly, as the Tea app breach showed.

Do I need App Check if my Security Rules are good?

They do different jobs, so you want both. Security Rules decide what an authenticated user is allowed to do. App Check decides whether the request even came from your real app, rather than a script using your public config. Rules are the priority; App Check is the next layer.

Should I rotate my Firebase apiKey if it's in my code?

No. It's public by design, so rotating it gains you nothing and only risks breaking your app. The key where rotation actually matters is the service-account key — if that ever shipped in client code or a public repo, rotate it immediately and audit for misuse.

The bottom line

Firebase security isn't about hiding your config — that's public on purpose. It's about three controls: Security Rules on your database, locked rules on your Storage, and App Check on your traffic, plus never letting the service-account key leave your server. An attacker can read your public config and probe your rules in minutes; the point is to find the open rule or open bucket first, and to keep checking, because your AI ships new collections, new buckets, and new gaps every time you add a feature.