This one has a twist. The Firebase config apiKey that Firebase Studio puts in your client is public by design and is usually not the problem, it only identifies your project. The real risks are two different things: permissive Security Rules that leave your database open, and a service account key, which is a true secret that must never be exposed.
Why it's a problem
Because the client apiKey is meant to be public, people assume Firebase is safe, and that assumption is the risk. What actually protects your data is Security Rules, and a test-mode or allow-all rule lets anyone read and write everything. Separately, a service account key grants full admin access to your project and must be rotated immediately if it ever reached client code or a repo.
How to fix it, in order
- 1Confirm which key it is. The client config apiKey is public and expected. A service account key (a JSON credential) is secret. If a service account key was exposed, rotate it in the Google Cloud console now.
- 2Lock down Security Rules. Write rules that scope reads and writes to the authenticated owner. Never ship test-mode or allow-all rules.
- 3Keep server credentials server-side. Service account keys belong only in server code or trusted environments, never in the client or the repo.
- 4Verify access. Try to read data you should not have access to using the public config. If it works, your rules are not restricting anything.
Why Firebase does this
The generated app includes the public config so it can talk to Firebase, which is correct. The gap is that securing the database is a manual Security Rules step the generated code cannot do, and a service account key can be introduced later for admin tasks and mistakenly placed where the client can see it.
Stop it happening again
Treat the client apiKey as public but assume nothing protects your data except your Security Rules. Configure rules on every collection, keep service account keys server-side, and scan for any secret credential that reached the client or repo.
The quick fix
- The client apiKey is public and usually fine; do not panic over it.
- Rotate any exposed service account key immediately.
- Write Security Rules that restrict access; never ship test-mode rules.
- Keep service account keys strictly server-side.
Common questions
If the Firebase client apiKey is meant to be public, why does Prbl flag it?
Prbl flags it to confirm it is the public client key and not a service account credential, and to check whether Security Rules are configured. The key itself is expected; the rules question is what matters.
What do minimal Firebase Security Rules look like?
A rule that restricts reads and writes to the authenticated owner: allow read, write: if request.auth != null && request.auth.uid == resource.data.userId;
Is a service account key in a .env file on the server safe?
Safe for server-side use, as long as the .env is gitignored and never reaches the client. Keep it in your hosting environment's secret manager and never check it into source control.