← All posts
firebase api key fix vibe codingleaked firebase api keyvibe coding securityfirebase securitysecret leak scanner

Firebase API Key Fix Vibe Coding: Secure Your App in 5 Steps

O

OverMCP Team

Quick answer

If you've exposed a Firebase API key in your vibe-coded app, revoke it immediately in the Firebase Console and restrict the new key to your app's domain or IP. Then audit your codebase with a secret leak scanner to catch any other hardcoded secrets. Finally, move all keys to environment variables and never commit them to version control.

What to check first

Before you panic, verify whether your key is actually exposed and what damage it could cause:

  • Check your GitHub public repos: Search for apiKey: "AIza or firebaseConfig in your code. Even private repos can leak if you've ever pushed a branch.
  • Check your client-side JavaScript: Open your deployed site, view page source, and look for firebase.initializeApp or any config object containing apiKey.
  • Check your environment variables: If you're using Vercel, Netlify, or Replit, ensure the Firebase config is injected via process.env and not hardcoded.
  • Check your .gitignore: Make sure .env files are listed. If not, your keys may be in your commit history.
  • Check Firebase Console billing: Look at the Usage tab for any unusual spikes that suggest someone is using your key maliciously.
  • Note: A Firebase API key is not a secret by itself—it's meant to be client-facing. But if it's not restricted to your app's authorized domains, anyone can use it to hit your Firestore, Realtime Database, or Authentication endpoints and potentially read/write data if your security rules are weak.

    Step-by-step fix

    Step 1: Revoke the exposed key and create a new one

  • Go to the Firebase Console and select your project.
  • Click the gear icon → Project settingsGeneralWeb API Key.
  • Click the three dots next to the key and select Delete API key.
  • Click Add API key → choose Android/iOS/WebWeb key.
  • Give it a name like "Production Web Key" and click Create.
  • Step 2: Restrict the new key

    With the new key selected, scroll down to Key restrictions:

  • Application restrictions: Choose HTTP referrers (web sites) and add your domain (e.g., https://yourdomain.com/*). For local development, add http://localhost:* and http://127.0.0.1:*.
  • API restrictions: Click Restrict key and select only the Firebase APIs you use (e.g., Cloud Firestore, Firebase Auth, Firebase Realtime Database).
  • This ensures even if someone extracts the key from your client-side code, they can't use it from an unauthorized domain.

    Step 3: Update your app's environment variables

    Replace the old key with the new one in your environment variables. For example, in a Next.js app:

    // .env.local (never commit this file!)
    NEXT_PUBLIC_FIREBASE_API_KEY=AIzaSyNewKeyHere
    NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN=your-project.firebaseapp.com
    NEXT_PUBLIC_FIREBASE_PROJECT_ID=your-project-id

    Then reference them in your Firebase config:

    // lib/firebase.js
    import { initializeApp } from 'firebase/app';
    import { getFirestore } from 'firebase/firestore';
    
    const firebaseConfig = {
      apiKey: process.env.NEXT_PUBLIC_FIREBASE_API_KEY,
      authDomain: process.env.NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN,
      projectId: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID,
    };
    
    const app = initializeApp(firebaseConfig);
    export const db = getFirestore(app);

    Step 4: Clean your git history (if the key was ever committed)

    If the key was pushed to a public repo, remove it from history using git filter-branch or BFG Repo-Cleaner:

    # Using BFG (recommended)
    bfg --replace-text passwords.txt  # create passwords.txt with the old key

    Then force push to overwrite history:

    git push --force --all
    Important: Even after force pushing, the key may still be accessible via cached forks or clones. Revoking the key (Step 1) is the only true fix.

    Step 5: Set up continuous monitoring

    To prevent this from happening again, integrate a continuous security monitoring tool that scans every commit and deployment for leaked secrets. Many vibe-coded apps rebuild frequently, so manual checks aren't enough.

    Common mistakes

  • Thinking the API key is a secret: Firebase Web API keys are designed to be public. The real risk is that an attacker can use your key to make calls to Firebase services if your security rules are too permissive. Always restrict the key AND set proper Firebase Security Rules.
  • Hardcoding keys in client-side code: AI coding tools like Cursor and Bolt.new often generate Firebase config directly in components. Always move these to environment variables before deploying.
  • Ignoring the .env file in .gitignore: Many vibe-coded apps start from templates that don't include a proper .gitignore. Check that .env, .env.local, and .env.* are listed.
  • Not restricting API keys after creation: The default key has no restrictions. Without domain or API restrictions, anyone can use your key from any website.
  • Assuming private repos are safe: GitHub private repos can still be exposed if you add a collaborator, fork the repo, or use CI/CD logs that leak environment variables.
  • Why vibe-coded apps are especially vulnerable

    AI coding assistants often generate Firebase initialization code by inserting your config directly into a JavaScript file. They don't automatically set up environment variables or key restrictions. A typical Cursor session might produce:

    // Generated by Cursor - DANGER: hardcoded keys
    const firebaseConfig = {
      apiKey: "AIzaSyD...",
      authDomain: "myapp-12345.firebaseapp.com",
      // ...
    };

    This is convenient for prototyping but dangerous for production. Always refactor this out before deploying.

    How to prevent future leaks

  • Use environment variables from the start: Whether you're using Cursor, Bolt.new, or v0, prompt the AI to use process.env for all Firebase config values.
  • Run a secret scanner before each deploy: Use a free AI app security scanner to check your codebase for exposed keys.
  • Set up Firebase Security Rules: Even if your key is restricted, weak rules can still expose your data. For example, don't set read: true on your Firestore database.
  • Monitor your Firebase usage: Enable billing alerts and check the Usage tab regularly for unexpected spikes.
  • FAQ

    What happens if my Firebase API key is leaked?

    If your API key is public but not restricted, an attacker can make authenticated requests to your Firebase project, potentially reading or writing data if your security rules are permissive. They could also abuse Firebase Auth to sign up users or trigger Cloud Functions, leading to unexpected bills.

    Can I just delete the leaked key and create a new one?

    Yes, that's the first step. But you must also restrict the new key to your domain and APIs. Otherwise, the new key is just as vulnerable. Also, update your environment variables and remove the old key from your git history.

    Do I need to change my Firebase project ID or other credentials?

    No, the project ID and other non-secret credentials (like authDomain) are public-facing and can remain the same. Only the API key needs to be revoked and replaced. However, if you also leaked a service account private key or database password, those are serious secrets that must be rotated immediately.

    ---

    Protect your vibe-coded app from day one. Use [OverMCP](https://www.overmcp.com/) to automatically detect leaked secrets before they become a problem.

    Is your app secure?

    Free scan in 30 seconds. No signup needed.

    Scan My App Free