41–50 of 325 posts
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?
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
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?
I said this when this finding was originally posted and I'll say it again: This is by far the worst security incident Google has ever had, and that's why they aren't publicly or loudly responding to it. It's deeply embarrassing. They can't fix it without breaking customer workflows. They really, really want it to just go away and six months from now they'll complete their warning period to their enterprise contracts…
This is only a little billing leakage, Operation Aurora in 2009 was 100x worse
[1] https://trufflesecurity.com/blog/google-api-keys-werent-secr...
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?
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.
I said this when this finding was originally posted and I'll say it again: This is by far the worst security incident Google has ever had, and that's why they aren't publicly or loudly responding to it. It's deeply embarrassing. They can't fix it without breaking customer workflows. They really, really want it to just go away and six months from now they'll complete their warning period to their enterprise contracts…
At some point, when it appeared 2 months ago on HN and they still did nothing about it, intentionality can be assumed.
> Are there recommended safeguards beyond ... moving calls server-side? This implies the API calls originated in the client, suggesting the client may have had they API key.
That's standard for Firebase apps. It's also recommended by Google (they describe the keys as "public by design").
I had a similar experience with GCP where I set a budget of $100 and was only emailed 5 hours after exceeding the budget by which time I was well over it.
It's mind boggling that features like this aren't prioritized. Sure it would probably make Google less money short term, but surely that's more preferable to providing devs with such a poor experience that they'd never recommend your platform to anyone else again.