Step-by-Step Guide
6 steps

Firebase API Key Exposed? What Is Safe and What to Fix

Found an AIza... Firebase key in your browser bundle or GitHub repository? A Firebase client API key is public by design and does not authorize access to your data. Do not rotate it blindly. First confirm it is restricted to Firebase APIs, test your Security Rules, enable App Check where supported, and make sure you did not expose a service account or another privileged credential.

Scan Your App Now

Find security issues automatically before attackers do.

Follow These Steps

1

Understand that Firebase API keys are public by design

Firebase API keys identify your project but do not grant data access. Security is enforced by Firestore Security Rules, Realtime Database Rules, and Storage Rules.

Code Example
// This is NORMAL and SAFE
const firebaseConfig = {
  apiKey: "AIzaSyBxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  authDomain: "your-project.firebaseapp.com",
  projectId: "your-project",
  storageBucket: "your-project.appspot.com",
  messagingSenderId: "123456789",
  appId: "1:123456789:web:abc123"
}

Firebase configuration values are expected in client code. Hiding the same value in a public environment variable does not add security.

2

Focus on Security Rules instead

The real security of your Firebase app comes from Firestore Security Rules. Ensure they are restrictive.

Code Example
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // INSECURE - never use in production
    // match /{document=**} { allow read, write: if true; }
    
    // SECURE - scope to authenticated user
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}
3

Verify API restrictions in Google Cloud Console

Firebase-provisioned keys should be restricted to Firebase-related APIs. Use a separate, tightly restricted key for non-Firebase Google APIs, and test any application restrictions before enforcing them.

Code Example
// Google Cloud Console > APIs & Services > Credentials
// 1. Select the key used by your Firebase app
// 2. Review API restrictions
// 3. Allow only the Firebase-related APIs the app uses
// 4. Use a separate key for Maps, Gemini, or other Google APIs
// 5. Add platform/application restrictions where supported and test the app
4

Check for credentials that are actually secret

Service account private keys, database passwords, Admin SDK credentials, and third-party secret keys must never appear in client code or public Git history.

Code Example
# Search for likely secrets (not the Firebase client config)
rg "private_key|service_account|sk_live|sk-proj|DATABASE_URL|client_secret" .

# If a real secret was exposed, revoke or rotate it first,
# then remove it from code and repository history.
5

Enable App Check for additional protection

App Check verifies that requests come from your legitimate app, adding another layer of security beyond the API key.

Code Example
import { initializeAppCheck, ReCaptchaV3Provider } from 'firebase/app-check'

const appCheck = initializeAppCheck(app, {
  provider: new ReCaptchaV3Provider('your-recaptcha-site-key'),
  isTokenAutoRefreshEnabled: true
})
6

Scan for real vulnerabilities

Run a vas scan to find actual security issues in your Firebase app, like open Security Rules or missing authentication.

What You'll Achieve

You have classified the exposed value correctly, restricted the client key to the APIs it needs, tested Security Rules, enabled App Check where appropriate, and rotated any genuinely privileged credential. The result is meaningful protection rather than hiding a value that browsers must receive.

Common Mistakes to Avoid

Mistake

Trying to hide the Firebase API key in environment variables

Fix

The Firebase config must be in client code to initialize the SDK. Moving it to a .env file with NEXT_PUBLIC_ prefix changes nothing since it is still in the browser bundle.

Mistake

Thinking an exposed Firebase client key proves your database is exposed

Fix

The client key identifies the project. Test Firestore, Realtime Database, and Storage Security Rules to determine what data is actually reachable.

Mistake

Treating every AIza key as harmless

Fix

Confirm the key is the Firebase client key and is restricted to Firebase-related APIs. Separate keys used for paid Google APIs can create quota or billing risk.

Frequently Asked Questions

Is my Firebase API key (AIzaSy...) a security risk?

A Firebase client API key is public by design and does not authorize data access. Risk appears when the key is unrestricted for non-Firebase Google APIs, Security Rules are open, App Check is absent where abuse matters, or the exposed value is actually a privileged credential.

Should I report an exposed Firebase API key as a vulnerability?

Not by itself. Record it as expected public configuration, then verify API restrictions and test Security Rules. Report open data access, quota abuse, an exposed service account, or another concrete impact instead.

What about the other config values like appId and messagingSenderId?

All Firebase config values are public. None of them are secrets. They are used to configure the Firebase SDK client and do not grant any privileged access.

Related Guides

Add Security Rules to FirebaseSecure Your Firebase AppSecure Your Firebase Studio App

Explore Related Resources

Ready to Secure Your App?

vas automatically scans your deployed app for the security issues covered in this guide. Get actionable results in minutes.

Start Security Scan