Google API keys weren't secrets, but then Gemini changed the rules

In Google AI Studio, Google documentation encourages to deploy vibecoded apps with an open proxy that allow equivalent AI billing abuse - giving the impression that the API key were secure because it is behind a proxy. Even an app with 0 AI features exposes dollars-per-query video models unless the key is manually scoped. Vulnerable apps (all apps deployed from AI Studio) are easily found by searching Google, Twitter or Hacker News. https://github.com/qudent/qudent.github.io/blob/master/_post...

> Leaked key blocking. They are defaulting to blocking API keys that are discovered as leaked and used with the Gemini API.

There are no "leaked" keys if google hasn't been calling them a secret.

They should ideally prevent all keys created before Gemini from accessing Gemini. It would be funny(though not surprising) if their leaked key "discovery" has false positives and starts blocking keys from Gemini.

The headline really undersells the point and reads like clickbait. "Things were fine, then she turned the tables. Watch what happens next." I avoided even opening this article several times out of distaste for the headline. It should be something like "Google leaves your Gemini data vulnerable to non-secret API key exploit."

Ohh so that's how that happened. I had noticed (purely for research purposes of course) that some of Google's own keys hardcoded into older Android images were useable for Gemini (some instantly ratelimited so presumably used by many other people already but some still usable) until they all got disabled as leaked like two months ago. They also had over time disabled Gemini API access on some of them over them beforehand.

What's frustrating is that a lot of these keys were generated a long time ago with a small amount of GCP services that they could connect to. (Ex. Firebase remote config, firestore, etc.)

When Gemini came around, rather than that service being disabled by default for those keys, Gemini was enabled, allowing exploiters to easily utilize these keys (Ex. a "public" key stored in an APK file)

This seems so… obvious? How can a company of this size, with its talent and expertise, not have standardized tests or specs preventing such a blatant flaw?

Someone on the Google subreddit did report getting a 80k bill yesterday from a Gemini key.

I’m very careful with Google and co since they’re so intent on infinite scaling access to your wallet

Is the implication at the end that Google has not actually fixed this issue yet? This is really bad; a massive oversight, very clearly caused by a rush to get Gemini in customers' hands, and the remediation is in all likelihood going to nuke customer workflows by forcing them to disable keys. Extremely bad look for Google.

This is mind-blowing, and it defies all security common sense. Changing global API keys permissions? Come on! We’re accustomed to seeing issues like this from Redmond but didn’t expect it from Google.

This totally reminds me of SSN use, when initially they were just a number (not secret) to identify a person, and then suddenly people started to use them as a key for authorisation, because someone had a bright idea how to implement things fast/simple/cheap (cheap part comes at expense of others)

I think this is making at least some waves in google. I literally just got an email from them with the subject "[Action Advised] Review Google Cloud credential security best practices"

A slew of recommendations, one of them being:

Disable Dormant Keys: Audit your active keys and decommission any that show no activity over the last 30 days.

(Although I don't think this even addresses the underlying issue)

Many people wanted to be able to set a spending limit on google cloud account for many years but they were unable to implement anything, always suggesting a workaround by hosting a Cloud Run function which would remove billing from a project via API https://docs.cloud.google.com/billing/docs/how-to/disable-bi...

Unrestricted API keys were always secrets. They are created on a page called "Keys & Credentials". The fact that Google even allows unrestricted keys to be created has been a long standing security problem. The fact their docs encouraged it remains unforgivable.

> Retroactive Privilege Expansion. You created a Maps key three years ago and embedded it in your website's source code, exactly as Google instructed. Last month, a developer on your team enabled the Gemini API for an internal prototype. Your public Maps key is now a Gemini credential. Anyone who scrapes it can access your uploaded files, cached content, and rack up your AI bill. Nobody told you.

Malpractice/I can't believe they're just rolling forward

This is just embarrassing. It doesn’t even really qualify as a security vulnerability, more like a fatal flaw in the system’s design. I can see why the team pushed back on fixing it, seems like a massive pain.

It feels like something that would happen if you outsourced planning to an LLM.

> This makes sense. These keys were designed as project identifiers for billing, and can be further restricted with (bypassable) controls like HTTP referer allow-listing. They were not designed as authentication credentials.

Can't you just run up a huge bill for a developer by spamming requests with their key? I don't see how this wasn't always an issue?

Woof. Impedance mismatch outcome from moving fast - the GCP auth model was never designed to work like oAI's API key model; this isn't the only pain point this year, but it's a nasty one. I'm sympathetic, except that dealing with GCP has always been a huge pain in the ass. So I'm a little less sympathetic.

Can’t wait til someone makes a Gemini prompt to find these public keys and launch a copy of itself using them.

API keys were always secrets. They control billing for heaven's sake. If you had any per-call billed APIs (like some of the voice processing APIs) enabled on the project then they're effectively keys to your pocket book. Otherwise they're a key tool to manage denial-of-service attacks.

this is what happens when a "public" key type quietly turns into a privileged key type without forcing people to re-scope it, not really a dev mistake IMO, it's a platform design bug and google needs hard separation between publishable and secret keys or this repeats every time they ship a new API. pretty disappointed in google tbh, looked up to them for security for the longest time

Am i reading this right - it was like impossible to get an api key for gemini but actually i could have just grabbed an API key from someone's google maps site and gotten started right away?

So even if they fix the issue, it sounds as though you can still shoot itself in the foot by essentially being at to arbitrarily change an existing key from “not a secret” to “is a secret”?

Even if you have a key that you use for maps (not secret) someone could add the generative AI scope to it and make it now necessarily secret (even though it’s probably already publicly available)?

Who knew there were downsides to forcefeeding your product to an unwilling audience?

This whole Gemini roll-out has me reminded of the Google '+' days when they thought they were going to die if they didn't do social.

What are the chances this isn't intentional to some extent? This wouldn't be the first time we've traded downstream legal trouble for short term gains.

Making AI utilization appear to go up is the only thing that matters right now if you're in the boardroom at one of these companies. Whether or not that utilization was actually intended by the customer is entirely irrelevant. From here, the only remaining concern is mitigating legal issues which google seems to be immune to.

the credential didn't change. the permissions changed underneath it. that's the worst kind of privilege escalation because nobody has a reason to go back and audit something they were told was safe a decade ago.

Arguably, calling it a key while insisting it's a non-sensitive ID was a mistake to start with

Changing the semantics of existing non-key keys, making them actually keys is horrendous

I reported few instances last year, some companies fixed it, some other didn't even understand the problem (or ghosted me).

They said they were going to disable it for leaked keys isn't better to just disable it for leaked keys. Isn't better to make the default behavior from now on to not have access to Gemini or I misunderstood?

This firm is doing great work, I still refer to this post ("Anyone can Access Deleted and Private Repository Data on GitHub"): https://trufflesecurity.com/blog/anyone-can-access-deleted-a...

> Your public Maps key is now a Gemini credential. Anyone who scrapes it can access your uploaded files, cached content, and rack up your AI bill.

This destroys Google's right to pursue an unpaid "AI" bill as a debt.

I’ve been exploring this exact problem space from the angle of extreme constraints (single-digit MB memory, no cloud assumptions). I documented what broke first and why here, in case it’s useful: https://github.com/nullclaw/nullclaw

Happened to me recently, I got a warning in Gemini Studio that a key leaked. I was perplexed initially and then realized what had happened. The proper fix is to limit the key to just Maps APIs. Of course even this is not so easy, as there's a long list of APIs with complicated names. It was at least limited to my domain.

This is true but also not as new as the author claims. There have been various ways to abuse Google API keys in the past (at least to abuse them financially) and it’s always been very confusing for developers.

Seems like the kind of bug caused by using Gemini to vibe code the GCP.

> 2,863 Live Keys on the Public Internet

It will be more interesting if they scan GitHub code instead. The number terrified me. Though I am not sure how many of that are live.

Uh what? Google maps API keys have always been separate and they have always adviced to lock it down to your domain such that others can abuse it.

Thousands of engineers. Culture rot.

Since I've never used them, how could API keys for Firebase or Maps be safe for embedding in client side code?

I mean, I get that authentication to the service is performed via other means, but what's the use of the key then?

I'm guessing it's just a matter of binding service invocations to the GCP Project to be billed, by first making sure that the authenticated principal has rights on that project, in order to protect from exfiltration. That would still be a strange use case for what gets called an "API key".

This is so weird, this feels like an incredibly stupid bug that any average developer would've noticed, but Google is so incredibly selective with their tech screen. What exactly is the point of those if they're going to fuck up in obvious ways?

it's just firebase part 2

Wait, I can get such a key and perform gemini API requests with curl? (probably limited in some ways)

Great write-up. Hilarious situation where no one (except unwieldiness) is the villain.

I'm a bit surprised by the timeline which seems to say that:

- 6 weeks ago Google said they would fix it

- 3 weeks ago Google said they were working on it

...but we're publishing the info anyway, so everyone can go nuts with it.

Dang, another obvious reason (among many others) you shouldn't be uploading documents to any LLM client (or use them on anything important).

[dead]