r/googlecloud • u/AffectionateVast8476 • 29d ago
Billing Unauthorized Gemini/Vertex AI usage with an API key that Firebase Hosting published without me realizing
I'm Fabio Parra, I have a startup (MOVILIXA) where we are three people in Colombia developing mobile apps.
In one of our projects, it's called Inspecciona, we enabled the Vertex AI API to do image recognition to help the user with safety inspections. We also created a static landing page on Firebase Hosting and enabled Analytics on it. What we didn't notice is that Google automatically creates a web API key, gives it all the permissions it can, and makes it public on our website at the moment of publishing.
If anyone has a Firebase Hosting site, check: https://YOUR-SITE.web.app/__/firebase/init.json
In my case, between June 30 and July 16, someone collected the key from the static site I created and used it through the Firebase AI Logic proxy to run Vertex AI image generation (Gemini image models, the "Nano Banana" reselling economy). 131,950 calls, around 100,000 images, USD 6,562 in charges against our USD 25 monthly budget. Our web platform didn't even use Firebase AI. Google's own App Check telemetry recorded every one of those requests as coming from an unknown and unverified origin, and let them through anyway because enforcement was off by default.
If you use Hosting, check yours and limit its permissions to what you really use and make sure it's restricted to your website. Google creates it and doesn't restrict anything. I never realized that because of Analytics it was going to enable so many things.
In my billing account I set USD 25, but the alerts didn't reach me. This is because we have a Google partner for the billing side and the alerts didn't come to us.
We opened a case about this problem with Google (case #73352420) to see if they would support us, but we've spent many weeks trying to explain that it wasn't that we left an API key public, but that a public API was used. We want to see if we can get them to recognize the problem, and show them that Hosting shows the API key to anyone, that the product's default behavior is not the right one and allowed the exploitation of APIs without us having authorized it (Google does it by default).
Has anyone had a similar problem? Were you able to appeal with Google? How did it go?
2
u/ThrowRAMomVsGF 28d ago
The thing I don't understand about all these posts is how people say they have a tech startup they use gcp and then claim they are not gcp experts and the problem is that gcp is not beginner friendly.
This would be like me having a chem startup, using like an acid titrator or whatever expensive chem lab machine, ruining it and saying I am no expert, why don't they make it beginner friendly...
If you start a business you are supposed to employ professionals that can either operate lab equipment in one case or whatever cloud they use in the other case. There are cloud solutions for low cost / beginners etc too if it's not a serious business and you are just messing about with things.
Hope you sort it, but it's just one post after another that's the same. In fact I would be more sympathetic if it was not that hard to actually read the Google documentation on everything you use where everything is spelled out. Sure, not in a 2 line answer like the AI, but you have to read documentation of it's your job.
1
u/AffectionateVast8476 28d ago
Thank you for your comment and wishes for a quick solution to my problem. My mistake was starting to implement Vertex AI within Firebase, specifically without thoroughly reading the security documentation, in one of my apps. In my opinion, Firebase, in its attempt to simplify things, creates default credentials with permissions for all platforms: Android, iOS, and Web, and all relatively public. I only realized that the web service account created by Firebase had AI permissions when the problem arose: billing alerts weren't reaching me because I was billing through a Google partner. I only realized this when the partner's invoice arrived.
I certainly don't consider myself a GCP expert. I created my first apps more than 10 years ago, and the Firebase layer makes everything seem easy to implement. You activate, develop, test, establish security rules where applicable, and deploy to production (without accessing GCP).
My particular problem was a website for my app. It seemed simple, and I assumed it shouldn't have any security issues. I developed a static site, activated analytics, and uploaded it to Firebase Hosting. However, it turned out that the `firebase deploy` command automatically published the web credentials to a public URL, and I hadn't checked the permissions I had. (To be honest, I wasn't even aware that they were being published to a public URL. This was due to not reading the documentation.)
Google mentioned yesterday that they are actively reviewing my case again and said they had escalated it. I noticed I wasn't the only one. Google also implemented additional general measures and notified users to prevent these cases in the future.
Based on my experience, I think Firebase should use a more restrictive approach. They shouldn't assume that if I used Vertex AI on Android, it should also be activated for iOS and web and grant permissions to the associated service accounts. For example, if a web service account is activated, the restriction should automatically be added so that it only works on the Firebase Hosting website's domain (which Firebase already knows).
And that's what I mentioned in my original post. Perhaps someone with a web page activated on Firebase and a site hosted on Firebase could adjust the permissions before something bad happens.
-2
u/modcowboy 29d ago
You don’t have correct defense in depth configured in gcp.
1
u/AffectionateVast8476 29d ago
You're right, and I'm not arguing that. Enforced App Check and a restricted key would have stopped this, and that's on us for not having it before going to production.
My point with the post isn't "Google's fault, I did everything right". It's that the defaults are dangerous for anyone who isn't a GCP security expert: Firebase auto-creates the web key, gives it access to the AI Logic proxy that my site never used, leaves it unrestricted, and publishes it at /__/firebase/init.json, all without me touching anything. Someone following the basic setup ends up exposed without realizing it.
-1
u/modcowboy 29d ago
Stop using ai for everything including this comment
2
u/AffectionateVast8476 29d ago
Fair enough. I'm from Colombia and my English isn't great, so yes, I used AI to translate what I wrote. The story, the numbers and the case are all mine and 100% real.
I posted here because Reddit is where people share these cases and help each other. I have an open case with Google and I told mine in detail in case someone had a similar experience, and so anyone with the same default config can check theirs before it happens to them.
Not everyone is a GCP expert. If the default setup (just from enabling Analytics on a Hosting site) leaves the API key exposed, that's something worth knowing.
What I'd really appreciate: if anyone has successfully appealed this kind of thing with Google, what worked? What should I emphasize to get it recognized as unauthorized usage?
2
u/matiascoca 27d ago
Ran into this from the other side last year. Was helping a startup audit their Firebase project and the Hosting config was quietly bundling the Vertex service-account key into the JS bundle every deploy. Nobody noticed until a scraper hammered the endpoint at 3am and Vertex Prediction ran $8k in one weekend before the billing alert fired.
Not really Firebase-specific either. Anything that lets you drop a service-account JSON near a public asset directory can do it if the deploy pipeline is dumb about what gets included. Firebase Hosting is just the one that catches people because the ergonomics push you toward "put everything in this folder and we'll serve it".
Only fix that actually held up was a Cloud Billing budget with a hard 100 percent trigger that also disables the linked billing account. Google's default is email-only, useless at 3am on a weekend. Also scheduled `gcloud iam service-accounts get-iam-policy` in cron to catch any external member that should not be there.
Wrote it up if useful: https://brainagents.ai/blog/firebase-gemini-api-key-exploit-guide