Building with AI for human benefit. Sharing how it's done.
That security alert about your “leaked” Firebase key? Probably a false positive.
Google Cloud Trust & Safety emails you:
We have detected a publicly accessible Google API key…
Your heart sinks. Then you realize: you put it there on purpose.
const firebaseConfig = {
apiKey: "AIzaSy...", // "THE LEAK"
projectId: "myproject",
};
This is standard Firebase Web SDK initialization. It’s supposed to be public.
Most API keys grant access. Firebase web keys just identify your project.
| Traditional API Key | Firebase Web Key |
|---|---|
| Acts as you | Identifies the project |
| Must be secret | Designed to be public |
| Security = hide it | Security = Firebase Rules |
The key gets them to the door. Security Rules decide if they get in.
match /ios-waitlist/{doc} {
allow create: if request.resource.data.keys().hasOnly(['email', 'timestamp']);
allow read, update, delete: if false;
}
match /{document=**} {
allow read, write: if false;
}
With these rules, even with your API key, attackers can:
Defense in depth. In GCP Console or via CLI:
gcloud services api-keys update YOUR_KEY_ID \
--project=YOUR_PROJECT \
--allowed-referrers="yourdomain.com/*,localhost:*"
Now the key only works from your domains.
read, write: if trueThe key is public. The rules are the security.
Epilogue: After writing this post, I deleted the feature entirely. No waitlist form, no Firebase SDK, no API key to defend. The scanners went quiet. Even when you can defend something as secure, ask if you need it at all. Sometimes the only winning move is not to play.