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…
theres not a single real gemini api key in the results
€54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
131–140 of 325 posts
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#132Earlier quoted context omitted.
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...
If one ignores 70% of the documentation, it makes for a demonizing blog post about it, sure. " 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 Firebas…
The only reasonable design is to have two kinds of API keys that cannot be used interchangeably: public API keys, that cannot be configured to use private APIs, and private API keys, that cannot be configured to use public APIs. There's no one who must use a single API key for both purposes, and almost all cases in which someone does configure an API key like that will be a mistake. It would be even better if the API keys started with a different prefix or had some other easy way to distinguish between the two types so that I can stop getting warnings about my Firebase keys being "public".
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#133Earlier quoted context omitted.
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…
I am referring to cross-zone within in the same region, so like us-central1-a to us-central1-b. These are building to building and often never cross public land.
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#134Take them to court.
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#135> We had a budget alert (€80) and a cost anomaly alert, both of which triggered with a delay of a few hours > By the time we reacted, costs were already around €28,000 > The final amount settled at €54,000+ due to delayed cost reporting So much for the folks defending these three companies that refused to provide hard spending cap ("but you can set the budget", "you are doing it wrong if you worry about billing", "ha…
I'd buy the technically impossible angle.
Even if you manage to get your microservices to synch every penny spent to your payment account at realtime (impossible) you still have to waiver the excess, losing some money every time someone goes past their quota.
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#136Can 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.
I doubt most cloud providers are even technically ready for true prepaid billing (which requires things such as estimating and reserving funds prior to paid operations, corresponding real-time two-way interfaces instead of just eventually consistent billing event aggregation etc).
In early mobile networks, the feature set for prepaid used to always lag behind, since real-time billing wasn't really a design consideration from the beginning.
I suppose rather than taking on that extra work or offering a reduced feature set or by building something best-effort and taking financial responsibility for its failures, if cloud providers can just get away with making this the user's problem, why wouldn't they?
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#137> We had a budget alert (€80) and a cost anomaly alert, both of which triggered with a delay of a few hours > By the time we reacted, costs were already around €28,000 > The final amount settled at €54,000+ due to delayed cost reporting So much for the folks defending these three companies that refused to provide hard spending cap ("but you can set the budget", "you are doing it wrong if you worry about billing", "ha…
> 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-...
Why is the default uncapped then other than the hopes of billing people who screw up or get exploited.
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#138> We had a budget alert (€80) and a cost anomaly alert, both of which triggered with a delay of a few hours > By the time we reacted, costs were already around €28,000 > The final amount settled at €54,000+ due to delayed cost reporting So much for the folks defending these three companies that refused to provide hard spending cap ("but you can set the budget", "you are doing it wrong if you worry about billing", "ha…
Yet another good reason to use a pre-paid service.
There are many to choose from now, like Openrouter.com, PPQ.ai, and routstr.com.
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#139Earlier quoted context omitted.
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…
I am referring to cross-zone within in the same region, so like us-central1-a to us-central1-b. These are building to building and often never cross public land.
Oh, yes! I forgot entirely about that case. You're right, egress traffic is charged there too.
Are the datacenters really located so close together? I assumed they weren't within walking distance of each other.
Re: €54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs
#140> We had a budget alert (€80) and a cost anomaly alert, both of which triggered with a delay of a few hours > By the time we reacted, costs were already around €28,000 > The final amount settled at €54,000+ due to delayed cost reporting So much for the folks defending these three companies that refused to provide hard spending cap ("but you can set the budget", "you are doing it wrong if you worry about billing", "ha…
I'd buy the technically impossible angle. Even if you manage to get your microservices to synch every penny spent to your payment account at realtime (impossible) you still have to waiver the excess, losing some money every time someone goes past their quota.
Sure, but 80 -> 28,000 -> 54,000 is a hell of a lot of slippage.
Trading platforms can guarantee a maximum slippage on stops, and often even offer guaranteed stops (with an attached premium), so I don’t see why Google and Firebase can’t do similar.
The way it works at present is ridiculous.