Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

€54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs

discuss.ai.google.dev

Post reply on HN
Print view View original

111–120 of 325 posts

Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs

#111

Post by lxgr »

singpolyma3 wrote: post #39
embedding-shape wrote: post #13

Considering 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?

Public API keys are a thing. Arguably they are poorly named (it's really more of a client identifier), and modeling them as primarily a key instead of primarily as a non-secret identifier can go very wrong, as evidenced here.

Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs

#112

Post by imafish »

comrade1234 wrote: post #68

Can you pre-load money into your account and have that be used until it's zero, at which time you have to load more? Deepseek does it this way.

OpenAI also worked like this last time I used it - not sure if that's changed.

Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs

#113

Post by lxgr »

fg137 wrote: post #59
singpolyma3 wrote: post #39

Earlier quoted context omitted.

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...

API keys for Firebase. While Google really messed up here, I doubt they ever published anything claiming that no Google API keys at all are secrets.

Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs

#114

Post by someothherguyy »

londons_explore wrote: post #70
embedding-shape wrote: post #44

Earlier quoted context omitted.

In the frontend world where you have client-side API keys talking directly to 3rd party services from the client. Think things like Google Maps and similar.

Which is a stupid idea for something where there is billing involved... Anyone on the internet can take that key and scrape the Google maps API (faking the referer header) and cost you $$$$$. Google should have simply done with by origin URL if they wanted stuff to be open like that.

Once upon a time Google maps loads were nearly free, and there was no way to restrict that key.

Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs

#115

Post by zozbot234 »

rtkwe wrote: post #105
Maxious wrote: post #98

Earlier quoted context omitted.

> The Gemini API supports monthly spend caps at both the billing account tier and project levels. These controls are designed to protect your account from unexpected overages, and the ecosystem to ensure service availability https://ai.google.dev/gemini-api/docs/billing#project-spend-...

The problem is it's specific to that API and defaults to uncapped so people who aren't using it and haven't heard about the issues with the Firebase API keys probably won't have set them.

Except that Google's own statements are extremely clear that "leaked" (i.e. public) API keys should not be able to access the Gemini API in the first place: "We have identified a vulnerability where some API keys may have been publicly exposed. To protect your data and prevent unauthorized access, we have proactively blocked these known leaked keys from accessing the Gemini API. ... We are defaulting to blocking API keys that are leaked and used with the Gemini API, helping prevent abuse of cost and your application data." https://ai.google.dev/gemini-api/docs/troubleshooting#google...

For extra clarity on the exact so-called "vulnerability" that Google identified, see: https://news.ycombinator.com/item?id=47156925 This describes the very issue where some API keys were public by design (used for client-side web access), so the term "leaked" should be read in that unusually broad sense. Firebase keys are obviously covered, since they're also public by design.

(As for "Firebase AI Logic", it is explicitly very different: it's supposed to be implemented via a proxy service so the Gemini API key is never seen by the client: https://firebase.google.com/docs/ai-logic Clearly, just casually "enabling" something - which is what OP says they did! - should never result in abuse of cost on the scale OP describes.)

Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs

#116

Post by lxgr »

dabedee wrote: post #42

As 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.

This is presumably by design: How can it be the vendor's fault if your custom billing protection implementation failed you at a critical time? Much harder to defend against a switch on their dashboard allowing billing overshoot.

Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs

#117

Post by sillysaurusx »

genxy wrote: post #100
sillysaurusx wrote: post #76

Earlier quoted context omitted.

Back in 2020 I had a similar situation. Ended up charging $500 due to an overnight TPU training run using egress bandwidth across zones. Google support was surprisingly understanding, after I explained the issue. They asked some clarifying questions. Then they said that they can offer a one time refund for this case. Since then I was paranoid not to accidentally do it again. I don't know whether GCP would refund a se…

GCP charging for interzone traffic is an interesting financial choice. They own all the infra and in many cases this is literally moving from building to building.

There's cross-region, and cross-zone. If both boxes are located within the same zone (e.g. us-east1) then the bandwidth is free, since it's intrazone traffic. Cross-zone egress traffic (e.g. us-east1 to us-central1) is billed at a certain rate, and cross-region egress traffic (e.g. us-east1 to europe-west8) is billed at a significantly higher rate.

Amusingly enough, ingress traffic seems to always be free. So you can upload as much data as you want into their cloud, but good luck if you need to get it out.

Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs

#118

Post by dminik »

sillysaurusx wrote: post #91
dminik wrote: post #62

Earlier quoted context omitted.

Try this one. Should remove most readme keys: Edit: self censor based on a request

I know you're well within your rights to post this, but would you consider replacing your comment with something like "It's easy to find working keys on github if you search the appropriate terms"? Think of it this way: although you're not to blame, HN drives a lot of traffic to your preconfigured github search. There are also bad actors who browse HN; I had a Firebase charge of $1k from someone who set up an automat…

I'm not opposed to even removing the comment outright.

That being said, GitHub does not even offer a time sorted search. Meaning that most of the results are going to be quite old and useless.

Second, API keys being shared on GitHub is quite an old problem. People setup automated scans for this sort of stuff. Me removing my comment isn't going to help anyone who already posted their API key online.

Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs

#119

Post by mdrzn »

embedding-shape wrote: post #13

Considering 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…

...JCip3SJw => Your API key was reported as leaked. Please use another API key.

...afnt0t-E => Your API key was reported as leaked. Please use another API key.

...-UYzYTYU => Your API key was reported as leaked. Please use another API key.

I think they all get immediately reported as leaked and invalidated.

Post reply on HN