How to Fix an Exposed Firebase API Key: Step-by-Step Guide

If you've accidentally exposed your Firebase API key in client-side code, a public repository, or an environment file, here's the short answer: revoke the key immediately, restrict it using Firebase Console, and implement security measures like Firebase Security Rules and App Check. Firebase API keys are not secret by design — they are meant to be public — but without proper restrictions, they can lead to unauthorized database access, cost spikes, and data breaches.

What Is an Exposed Firebase API Key?

A Firebase API key (often labeled apiKey in your config) is a simple identifier that routes requests to your Firebase project. Unlike a secret key, it's not encrypted and is visible in client-side code by design. However, if an attacker obtains it, they can interact with your Firebase services — like Firestore, Realtime Database, or Authentication — unless you have security rules in place. An exposed Firebase API key in a public GitHub repo, a .env file that got committed, or even in your browser's network tab can be abused for:

Step 1: Revoke the Exposed API Key

If you've confirmed your key is exposed (e.g., in a public repo or a leak scanner), immediately revoke it:

Note: Revoking the key will break any existing app instances until they update to the new key. Plan accordingly.

Step 2: Restrict the API Key

Never leave an API key unrestricted. In the Google Cloud Console, edit your key and apply these restrictions:

Example for a web app:

Allowed referrers:
https://yourdomain.com/*
https://*.yourdomain.com/*

Step 3: Enforce Firebase Security Rules

Your security rules are the real gatekeepers. Even with a valid API key, an attacker cannot access your data if rules are set correctly. Update your Firestore and Realtime Database rules to require authentication and validate data structure.

Firestore rules example:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Only authenticated users can read/write
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
    // Public data can be read by anyone, but only admins write
    match /public/{document} {
      allow read: if true;
      allow write: if request.auth != null && request.auth.token.isAdmin == true;
    }
  }
}

Realtime Database rules example:

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    },
    "public": {
      ".read": true,
      ".write": "auth.uid !== null && root.child('admins').child(auth.uid).exists()"
    }
  }
}

Step 4: Use Firebase App Check

App Check adds an additional layer of security by verifying that requests come from your app. It prevents API key abuse even if the key is exposed.

Now, only requests with a valid App Check token (generated by your app) will be accepted.

Step 5: Remove the Exposed Key from Public Sources

If your key was leaked in a public GitHub repo:

For .env files:

Step 6: Monitor and Audit

After fixing the exposure, monitor your Firebase project:

For ongoing scanning, consider a tool like OverMCP that automatically scans your GitHub repos and deployed apps for leaked Firebase API keys and other secrets.

Code Example: Safe Firebase Config Setup

Instead of hardcoding your config in JavaScript, use environment variables (but remember, they still end up in the client bundle):

// .env.local (never commit this)
NEXT_PUBLIC_FIREBASE_API_KEY=AIzaSy...
NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN=your-project.firebaseapp.com

// firebase.js (Next.js example)
import { initializeApp } from 'firebase/app';

const firebaseConfig = {
  apiKey: process.env.NEXT_PUBLIC_FIREBASE_API_KEY,
  authDomain: process.env.NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN,
  // ...
};

const app = initializeApp(firebaseConfig);

Even with env vars, the key is visible in the browser. That's why App Check and security rules are non-negotiable.

FAQ

What happens if my Firebase API key is exposed?

An exposed Firebase API key alone is not a direct security risk if you have proper security rules and App Check enabled. However, without restrictions, attackers can access your Firebase services, leading to data theft, unauthorized operations, and unexpected bills.

Can I keep using the same Firebase API key after exposure?

No. You should revoke the exposed key and create a new one immediately. Then apply API key restrictions and enforce security rules and App Check to prevent future abuse.

How do I know if my Firebase API key is exposed?

You can search for your API key in public GitHub repositories using GitHub's code search, or use a secret scanning tool like OverMCP that automatically detects exposed keys in codebases and deployments.