Hacker News Reader

Comment by embedding-shape | Hacker News Reader

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

Considering that the author didn't share what website this is about, I'd wager they either leaked it accidentally themselves via their frontend, or they've shared their source code with credentials together with it.

View on HN

> 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

This was reported a long time ago, and was supposed to be fixed by Google via making sure that these legacy public keys would not be usable for Gemini or AI. https://news.ycombinator.com/item?id=47156925 https://ai.google.dev/gemini-api/docs/troubleshooting#google... "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." Why are we hearing about this again?

the topic is cost overruns. they still allow for cost overruns. What's so hard to comprehend ?

FWIW, I just create a new Gemini API key today, and it had a different format than my old ones (created 10 days ago). So maybe they changed something?

A reply on OP's post states: "... We now generate Auth keys by default for new users (more secure key which didn’t exist when the Gemini API was originally created a few years ago) and will have more to share there soon. ..." So there is something new in that exact area but the details are forthcoming.

I think brand new stuff is probably safe, but old keys that currently being used for AI and non-AI stuff - if Google disables them for AI and it turns out it was actually not being exposed publicly, could disrupt a user's production service relying on AI.

They messed up by allowing old keys to be used for both private and public APIs in the first place, but now it's difficult for them to undo that for existing keys.

theres not a single real gemini api key in the results

Setup a watcher and you'll come across live ones eventually :)

Try this one. Should remove most readme keys:

Edit: self censor based on a request

Oh, wow.

this is such a wall of shame haha

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 automated script to hammer my endpoint as hard as possible, just to drive the price up. Point being, HN readers are motivated to exploit things like what you posted.

It's true that the github search is a "wall of shame", and perhaps the users deserve to learn the hard way why it's a good idea to secure API keys. But there's also no benefit in doing that. The world before and after your comment will be exactly the same, except some random Gemini users are harmed. (It's very unlikely that Google or Github would see your comment and go "Oh, it's time we do something about this right now".)

EDIT: I went through the search results and confirmed that the first several dozen keys don't work. They report as error code 403 "Your API key was reported as leaked. Please use another API key." or "Permission denied: Consumer 'api_key:xxx' has been suspended." So at least HN readers will need to work hard(er) to find a valid key.

I wonder how you report a gemini API key as leaked... Searching "report gemini api key leaked" on Google only brings up similar horror stories (a $55k bill, waived https://www.reddit.com/r/googlecloud/comments/1noctxi/studen...) and (a $13k bill from 3d ago https://www.reddit.com/r/googlecloud/comments/1sjzat3/api_ke...)

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.

I tried several dozen keys and they're all invalid, so I'm inclined to agree with you for this particular case. Thank you anyway for considering.

They have an automated process when keys get leaked on GH to get revoked automatically.

https://github.com/JustForSO/Sentra-Auto-Browser/blob/c048d3...

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

Um. What? In what world are API keys not secrets?

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.

In Firebase world API keys are for identification, not authorisation.

https://firebase.google.com/docs/projects/api-keys

Public by design: 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.

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 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. Set up API key restrictions

If you use API keys for other Google services, make sure that you apply API key restrictions to scope your API keys to your app clients and the APIs you use.

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

https://firebase.google.com/support/guides/security-checklis...

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

It'd be much better to call them something like "API usernames" or "API Client IDs". Though I also dislike the naming of "public keys" in asymmetric cryptography, for the same reasons, and I'm definitely not winning that fight!

They've updated that documentation significantly since thousands of projects were issued automatically generated Firebase API keys, pre-Gemini. See this version from Oct 2022: https://web.archive.org/web/20221001052713/https://firebase....

Back then, they did not automatically restrict those keys to only Firebase-related APIs.

So yes, if you read the documentation as it exists today it's much more clear what they're trying to prevent, but this is only after this issue has become more apparent.

> Back then, they did not automatically restrict those keys to only Firebase-related APIs.

If that is the case, why is this also in the 2022 link?

The part about scoping links to the restrictions documentation.

"Understand API keys

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. Learn more about API keys for Firebase.

Set up API key scoping

As an additional deterrent against an attacker attempting to use your API key to spoof requests, you can create API keys scoped to your app clients.

Keep FCM server keys secret

Unlike API keys for Firebase services, FCM server keys (used by the legacy FCM HTTP API) are sensitive and must be kept secret.

Keep service account keys secret

Also unlike API keys for Firebase services, service account private keys (used by the Admin SDK) are sensitive and must be kept secret. "

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.

Google Maps is not Firebase.

And "Firebase AI Logic" sure sounds like something easy to confuse with a Firebase service...

The same principle applies, though.

I'm absolutely not defending Google here, to be clear: Retroactively expanding the scope of an API "key" explicitly designated as "public/non-sensitive" is very bad.

But the concept itself does make some sense, and I'm just noting that there's precedent both across Google and other companies.

> The same principle applies, though.

How?

"Firebase AI Logic"

Is this a Firebase service or not?

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.

Yeah, just like “public key” in the cryptography sense

They’re not really cryptographic keys in that sense usually; I’d say “bearer token” is more accurate.

Reply on news.ycombinator.com