Scan free

Is it safe to expose a Firebase API key? Yes, the web apiKey isn't a secret. Your security rules are

Short answer: Yes. The apiKey in your Firebase web config is a project identifier, not a password, and Firebase's docs say it's fine to ship in code. What keeps your data safe is your Firestore, Realtime Database and Storage security rules, plus App Check. Open test-mode rules are the real leak. To see what your own live site gives away, run a free SniffPup scan (SniffPup is a free passive security scanner for vibe-coded apps). Only check sites you own.

Home › Guides › Is a Firebase API key safe? · Last updated · By Ember, SniffPup

The fast way: a free SniffPup scan runs 15 checks from the outside, including secrets in your public JavaScript. No signup. Ember can sniff what strangers can see, but she can't read your rules file, so check your rules too.

A 100 means no issues were found in our checks. It is never proof of security.

1. Why the web apiKey isn't a secret

Per the Firebase API keys docs, API keys for Firebase services only identify your Firebase project and app. They route requests and tie them to your project for quota and billing. None of the Firebase-related APIs use the key as authorization. Anyone can open your site's JavaScript and copy the config object, and that's expected:

const firebaseConfig = {
  apiKey: "AIza...",          // identifies the project, fine to ship
  authDomain: "your-app.firebaseapp.com",
  projectId: "your-app",
  storageBucket: "your-app.firebasestorage.app",
  appId: "1:...:web:...",
};

Moving it into an env variable doesn't hide it either: it still ends up in the bundle the browser downloads.

2. What actually protects your data: security rules

Access to Cloud Firestore, the Realtime Database and Cloud Storage is decided by Firebase Security Rules. When you create a database or bucket you pick locked mode or test mode, and test mode grants access to everyone. Firebase's insecure rules guide says that with open rules, anyone who guesses your project ID can steal, modify or delete the data. This is the pattern to look for:

// Firestore: NEVER ship this
match /{document=**} {
  allow read, write: if true;
}

// Realtime Database: NEVER ship this
{ "rules": { ".read": true, ".write": true } }

Replace it with owner-only rules, for example:

match /notes/{noteId} {
  allow read, delete: if request.auth != null && request.auth.uid == resource.data.owner;
  allow create: if request.auth != null && request.auth.uid == request.resource.data.owner;
  allow update: if request.auth != null && request.auth.uid == resource.data.owner
                && request.auth.uid == request.resource.data.owner;
}

Watch for rules that only check request.auth != null: any signed-in user, including one who just signed up, can reach every document. Test changes in the Firebase emulator or the Rules Simulator before you deploy. For a full walkthrough see Sniff and fix: Firebase rules and why Firebase test-mode rules leak.

3. App Check: only your app gets in

Firebase App Check checks that requests come from your real app (with reCAPTCHA Enterprise or reCAPTCHA v3 on the web, Play Integrity on Android, App Attest or DeviceCheck on Apple) and can reject the rest once you enforce it. It cuts abuse from scripts that copied your config. It doesn't replace rules: a request from your own app still needs rules that only allow the right user.

4. Restrict the key in Google Cloud

Public doesn't mean unlimited. The Firebase docs say keys Firebase creates are restricted to Firebase-related APIs by default (since May 2024), but check yours in the Google Cloud console under APIs & Services › Credentials:

5. Service account keys ARE secret

Don't mix the two up. The JSON private key you generate under Project settings › Service accounts for the Firebase Admin SDK gives full server access and ignores your security rules. Google's service account key best practices treat these keys as a serious risk if they leak. Keep it on the server, out of git and out of any NEXT_PUBLIC_ or VITE_ variable. If one has shipped, delete that key in Google Cloud, create a new one and update your server.

FAQ

Is the Firebase apiKey a secret?

No. Firebase's API key docs say API keys for Firebase services only identify your project and app, and that they're OK to include in code or checked-in config files. Access to data is controlled by Firebase Security Rules, App Check and Google Cloud IAM, not by hiding the key.

Then what actually leaks Firebase data?

Open security rules. Test mode, or rules like allow read, write: if true, let anyone who knows your project ID read, change or delete the data. Firebase's own docs warn never to use those rules in production. Rules that only check request.auth != null are another common gap: any signed-in user can reach everything.

Should I still restrict my Firebase API key?

Yes. In the Google Cloud console under APIs & Services > Credentials, keep the key limited to Firebase-related APIs. Use a separate, restricted key for anything else (Maps, Places), and never put the Gemini Developer API (Generative Language API) on a public key.

Is a Firebase service account key safe to expose?

No. A service account private key (the JSON file from Project settings > Service accounts) gives the Admin SDK full access and bypasses security rules. Keep it on the server only, never in frontend code or git, and if one leaks, delete it in Google Cloud and create a new one.

Does a clean SniffPup report mean my rules are right?

No. A score of 100 means no issues were found in our checks. It is never proof of security: an outside scan can't read your rules file, so test your rules too.

Sources: Firebase API keys, Avoid insecure rules, Firestore, Realtime Database and Storage security rules, App Check and Admin SDK setup docs, and Google Cloud service account key best practices. Checked November 1, 2026.

A score of 100 means no issues were found in our checks. It is not proof that your app is secure.