[flagged]
Reminder that HN is for humans. [1]
>Don't post generated comments or AI-edited comments. HN is for conversation between humans.
€54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
51–60 of 325 posts
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#52That's fucking bonkers that nothing in the system could see this as unusual and worthy of throttling. The embarrassment of this -- that a company LITERALLY SELLING machine learning services and expertise -- cannot spot such a thing... This should have led them to deal with this internally and refund it. Just... Wow Google.
The company selling machine learning services would probably love a €54k bonus
It's so funny seeing people thinking this is not by design
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#53Considering the amount of repositories on public GitHub with hard-coded Gemini API tokens inside the shared source code ( https://github.com/search?q=gemini+%22AIza%22&type=code ), this hardly comes as a surprise. Google also has historically treated API keys as non-secrets, except with the introduction of the keys for LLM inference, then users are supposed to treat those secretly, but I'm not sure everyone got that…
Um. What? In what world are API keys not secrets?
Google API keys have been used for ages on the frontend. For example on Google Maps embeds. Those are not possible without exposing a key to the frontend. They weren't secret, until Gemini arrived.
https://trufflesecurity.com/blog/google-api-keys-werent-secr...
https://medium.com/@ahhyesic/your-google-maps-api-key-now-ha...
https://www.malwarebytes.com/blog/news/2026/02/public-google...
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#54> Are there recommended safeguards beyond ... moving calls server-side? This implies the API calls originated in the client, suggesting the client may have had they API key.
It's "implied" throughout the whole post (or more like assumed that the reader understands this, because it's the basic premise of the problem). It's why they link to a post that explains the basic concept after a remark that "This describes our issue in more detail".
> tl;dr Google spent over a decade telling developers that Google API keys (like those used in Maps, Firebase, etc.) are not secrets. But that's no longer true: Gemini accepts the same keys to access your private data. We scanned millions of websites and found nearly 3,000 Google API keys, originally deployed for public services like Google Maps, that now also authenticate to Gemini even though they were never intended for it. With a valid key, an attacker can access uploaded files, cached data, and charge LLM-usage to your account. Even Google themselves had old public API keys, which they thought were non-sensitive, that we could use to access Google’s internal Gemini.
From Google themselves, in the Firebase docs:
> API keys for Firebase services are not secret. Firebase uses API keys only to identify your app's Firebase project to Firebase services, and not to control access to database or Cloud Storage data, which is done using Firebase Security Rules. For this reason, you do not need to treat API keys for Firebase services as secrets, and you can safely embed them in client code.
https://firebase.google.com/support/guides/security-checklis...>
... or at least that's what it used to say, until they quietly updated the docs to say this:
> API keys for Firebase services are not secret. API keys for Firebase services only identify your Firebase project and app to those services. Authorization is handled through Google Cloud IAM permissions, Firebase Security Rules, and Firebase App Check.
> All Firebase-provisioned API keys are automatically restricted to Firebase-related APIs. If your app's setup follows the guidelines in this page, then API keys restricted to Firebase services do not need to be treated as secrets, and it's safe to include them in your code or configuration files.
Followed later by (in different section):
> Use your Firebase-provisioned API keys only for Firebase-related APIs. If your app uses any other APIs (for example, the Places API for Maps or the Gemini Developer API), use a separate API key and restrict it to the applicable API.
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#55Also, can't you tie a key to a domain or IP address to help stop unauthorized usage?
Not if its publicly called from Javascript, as your user's browser will make those requests. You neither know their IP addresses, nor is the referer or origin header a safe choice as it can be spoofed outside of a browser.
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#56Earlier quoted context omitted.
Prepaid only is a fantastic idea, especially for dumb-ass startups. Limiting your liability to $100 or so sound like a big-ass W.
Yes, pre-paid would be fine and it's a well-understood pattern. No need to retire API keys.
Nobody is thinking about the stock owners, I see
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#57I thought the pricing model was meant to be a benefit of the cloud? All of a sudden, shock horror, paying by the minute turns out to be no cheaper and maybe even more expensive than just doing it yourself
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#58As others have said, this is a "feature" for Google, not a bug. There is no easy way to set a hard cap on billing on a project. I spent the better time of an hour trying to find it in the billing settings in GCP, only to land on reddit and figuring out that you could set a budget alert to trigger a Pub/Sub message, which triggers a Cloud Function to disable billing for the project. Insanity.
Call it for what it is, an antifeature, a trap for the user.
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#59Considering the amount of repositories on public GitHub with hard-coded Gemini API tokens inside the shared source code ( https://github.com/search?q=gemini+%22AIza%22&type=code ), this hardly comes as a surprise. Google also has historically treated API keys as non-secrets, except with the introduction of the keys for LLM inference, then users are supposed to treat those secretly, but I'm not sure everyone got that…
Um. What? In what world are API keys not secrets?
Google's world. They explicitly tell you that API keys are not secrets.
https://trufflesecurity.com/blog/google-api-keys-werent-secr...
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#60Earlier quoted context omitted.
Prepaid only is a fantastic idea, especially for dumb-ass startups. Limiting your liability to $100 or so sound like a big-ass W.
Prepaid only is a fantastic idea, until your site goes (desirably) viral and then gets shut off right as traffic is picking up, or you grow steadily and forget to increase your deposit amount and suddenly production is down. Billing alerts are a much better solution IMHO.
Let me choose. This common point seems more like a rationalization for the default behavior of hyperscalers. AWS isn't avoiding prepaid due to concern about my site's virality, just that prepaid = less money.