The Real Story Nobody's Talking About
A developer left their Firebase browser key exposed. Public. Accessible from the client side where it was never supposed to live. Someone found it, chained it to Gemini API calls, and ran up €54,000 in charges in thirteen hours. Not thirteen days. Thirteen hours.
This happened recently enough that the HN thread is still active. I'm not sure whether to be more alarmed by the attack itself or by how predictable it was. Maybe both. The thing that gets me is that we—as an industry—have known about this vulnerability pattern for years. Firebase documentation literally warns against it. Google's own best practices say it clearly. And yet developers keep making this exact mistake, over and over, because the friction between "getting it working" and "getting it working securely" is still massive.
Why This Keeps Happening (And Why Your Startup Might Be Next)
- Browser keys ship in client-side code because the SDK makes it stupidly easy
- Nobody runs cost monitoring alerts until after they've been charged. Usually around invoice time.
- Developers assume Google's free tier limits will save them
- Most startups don't have security reviews before shipping to production, or they do them wrong—checking for SQL injection while API keys sit exposed in environment files that get committed to GitHub
- The documentation exists but it's not a blocker during development
I've built products with Firebase. I've also nearly made this exact mistake twice. The second time, a contractor on my team had embedded a key in a public repo, and we caught it during code review by accident—pure luck. If that had made it to production, if someone had been monitoring that endpoint for vulnerabilities, I'd have been the one explaining a surprise charge to investors.
The Harder Question: Who's Responsible Here?
Google could require authentication flows server-side by default and make browser keys fundamentally limited in what they can access. They've had time. They could rate-limit aggressively based on API key patterns, which would have capped this at maybe €500 instead of €54k. I'm not sure why they haven't implemented this—perhaps it breaks the developer experience they've optimized for, or perhaps they've calculated that the support burden of locked-out developers exceeds the liability of occasional abuse cases. But here's the uncomfortable part: they probably make more money this way.
The developer is obviously responsible for their own keys. Full stop. That's non-negotiable. But responsibility and design are different things. A good system doesn't require perfect behavior from every human using it. It assumes humans will mess up and builds walls.
What Actually Works (Or At Least, What I Do Now)
- Server-side proxies for any sensitive API. Full stop. Your client talks to your backend; your backend talks to Gemini or wherever else.
- Separate credentials for development, staging, and production—this one's obvious but most indie projects skip it
- Cost alerts set to trigger at 20% of your monthly budget, not at your monthly limit
- Rotation schedules for API keys (monthly minimum)
- Audit logs. Actually read them. I set up a Slack webhook that pings me when my Gemini API quota usage spikes more than 50% month-over-month. It's saved me twice.
None of this is novel. None of this requires new technology. It requires discipline and architecture decisions made before you ship. And that's the real friction point, because making those decisions costs time you don't think you have when you're trying to get a prototype working.
The Part I'm Still Uncertain About
I don't know if the solution is better tooling from Google, better education for developers, or if the real answer is that some percentage of people will always get this wrong and that's just the cost of cloud infrastructure existing at this scale. Maybe companies should be insuring against this. Maybe developers should be required to take security courses before touching production APIs with real spending limits. Maybe Firebase should just cut off access immediately when it detects unusual patterns instead of waiting.
What I do know is that €54k in thirteen hours is expensive education. And somewhere right now, someone else is committing a browser key to a public repository.
