FireScan

Appearance

Is a Firebase API key a secret? ​

Short answer: no. A Firebase API key (the AIza... string in your firebaseConfig) identifies your Firebase project to Google's servers. It's designed to be included in web pages and mobile apps, and anyone can pull it out of your JavaScript bundle or APK in seconds. Google's own Firebase documentation says it's fine to include these keys in your code.

The real question is: what can someone do once they have it? The answer depends entirely on your Security Rules and a few project settings.

What the API key actually does ​

The key tells Google which project a request is for, and which APIs that project allows. On its own, it does not grant access to your data. When a client reads from Firestore, Realtime Database or Cloud Storage, Firebase checks your Security Rules to decide whether that request is allowed.

So with your API key and project ID, anyone can:

  • Make the same requests your app makes, from their own script instead of your UI
  • Create an account in your project, if email/password or anonymous sign-in is enabled (more on this below)
  • Call any Google API that's enabled for the project and not blocked by the key's restrictions

What they can't do is bypass your Security Rules. If your rules are right, the key is harmless. If your rules are wrong, hiding the key wouldn't have saved you, because it's in every copy of your app.

The mistake that actually leaks data ​

The common, dangerous assumption is: "Only my app knows the key, so only my app can talk to my database." That leads to rules like this:

javascript
// Firestore: anyone signed in can read and write everything
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.auth != null;
    }
  }
}

It looks safe because it requires login. But if email/password or anonymous sign-in is enabled, anyone can sign up using your public API key with a single request to the Firebase Auth REST API. No app needed. Once signed in, request.auth != null is true, and they can read every user's data.

request.auth != null checks that a request is authenticated (we know who you are). It doesn't check that it's authorized (you're allowed to see this data). You need both.

The fix: check ownership ​

javascript
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Each user can only touch their own document. Anything not matched by a rule is denied by default.

Real risks to manage ​

Even though the key isn't secret, there are a few things worth locking down.

1. Restrict which APIs the key can call ​

In the Google Cloud console (APIs & Services → Credentials), you can add API restrictions to your key so it only works with the Firebase APIs your app uses. This matters if other paid APIs are enabled on the same Google Cloud project: an unrestricted key could let someone run up usage on them at your expense. Use a separate, restricted key for anything that isn't Firebase.

Check which APIs your app needs before restricting, so you don't break sign-in or other features.

2. Decide whether open sign-up is what you want ​

If your app doesn't need public sign-up (for example, an internal tool), disable the providers you don't use in Authentication → Sign-in method. Consider turning on email enumeration protection, and use Firebase App Check to make it harder for scripts that aren't your app to use your backend.

3. Never put real secrets next to it ​

The Firebase key is public by design, but other keys are not. Third-party secrets (payment provider secret keys, AI API keys, database admin credentials, service account JSON) must never go in client code, including NEXT_PUBLIC_ / VITE_ environment variables, which get bundled into the browser. Keep them in Cloud Functions or another server, ideally in a secret manager.

4. Service account keys are secret ​

Don't confuse the client API key with a service account key (a JSON file with a private_key). Service account keys bypass Security Rules entirely and give admin access. If one ever ends up in a repo, client bundle or public bucket, revoke it immediately in the Google Cloud console.

How to check your project ​

  1. Read your rules for Firestore, Realtime Database and Storage. Look for if true, bare request.auth != null, and expired test-mode dates.
  2. Test from the outside. FireScan uses only your public project ID and API key, the same thing an attacker has:
bash
firescan > set projectID your-project-id
firescan > set apiKey AIza...
firescan > scan --unauth            # what's open with no login at all
firescan > auth --create-account    # can anyone sign up?
firescan > scan --all               # what a signed-in stranger can reach

If auth --create-account succeeds and scan --all then finds readable collections or nodes, you have the request.auth != null problem described above.

  1. Fix the rules, then scan again to confirm the findings are gone.

Only scan projects you own or have permission to test.

Summary ​

QuestionAnswer
Is the Firebase API key secret?No. It's meant to be public.
Should I hide or rotate it because it's in my app?No. Hiding it doesn't add security.
What protects my data?Security Rules, plus App Check and sensible Auth settings
What should I restrict?The key's allowed APIs in Google Cloud, and unused sign-in providers
What is secret?Service account keys and any third-party secret keys