Your Firebase Web API Key Is Public By Design — Here's Why That's Still a Problem

Every Firebase app ships with a Web API key baked into the frontend bundle. Google designed it this way — it's not a secret, it's a project identifier. So far so good.

The problem is what attackers can do with just that key, no credentials needed.

---

What the key actually unlocks

The Firebase REST API accepts the key as a query parameter. With it, anyone can call:

• accounts:signInWithPassword — brute-force any email/password account, no rate limit by default
• accounts:createAuthUri — probe whether an email address is registered (user enumeration)
• accounts:sendOobCode — spam password reset emails to any address in your system
• securetoken.googleapis.com/v1/token — exchange a refresh token for a fresh ID token

None of these give access to your Firestore data — Firebase Security Rules and your auth layer gate that. But they enable targeted attacks: enumerate your users, brute-force weak passwords, hammer the reset email flow until your SES quota dies.

Your key is in the JS bundle. Every script kiddie with DevTools has it.

---

The mitigations, in order of effort

1. HTTP referrer restriction — do this today, takes 2 minutes.

Cloud Console → APIs & Services → Credentials → your key → Application restrictions → HTTP referrers. Add your domains. The key becomes useless from arbitrary curl scripts or anything running outside your frontend.

2. Proxy /auth/refresh through your backend.

Refresh tokens are long-lived and should never live in the browser. Build POST /auth/refresh on your auth service — it calls Firebase's securetoken API internally and returns a short-lived ID token. The refresh token stays server-side and never touches the client.

3. Proxy /auth/login for email/password.

POST /auth/login { email, password } → your backend calls Firebase's signInWithPassword → checks account status → returns token. The Firebase key never touches the browser for this flow.

Note: this does not apply to social login (signInWithPopup / signInWithRedirect). That OAuth redirect chain must happen in the browser and cannot be proxied. If you use social login, the key stays in the frontend permanently — the security model shifts entirely to mitigations.

4. Firebase App Check — the real fix for automated abuse.

App Check attaches reCAPTCHA Enterprise or DeviceCheck proof to every Firebase request. Even with the key, automated scripts cannot generate a valid App Check token. This is the defense that actually raises the cost for attackers beyond trivial.

---

The mental model shift

Stop thinking of the Firebase key as a secret you need to protect. It's public infrastructure — Google designed it that way and the SDK puts it in your bundle regardless.

The security model is: accept the key is public, lock down what it can do. Referrer restrictions cut casual abuse. Proxying moves sensitive flows server-side. App Check defeats automation.

The key being in your bundle is fine. The key being the only gate between the internet and your auth endpoints is not.