Live data from Hacker News

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

trufflesecurity.com

131–140 of 326 posts

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

#131

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

Keys could have certain restrictions [1] such as HTTP Referer, which meant you couldn't just embed a map on your website and charge a different website for the views.

Not perfect protection of course - an attacker could spam requests with all the right headers if they wanted to - but it removes one of the big motivations for copying someone else's API key.

[1] https://docs.cloud.google.com/api-keys/docs/add-restrictions...

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

#132
post #120

Earlier quoted context omitted.

First of all, Google is a shell of the company it used to be. That said, I’d actually argue there’s an evolutionary explanation behind this where at a certain size, and more importantly complexity, an oversight like this becomes even more likely, not less.

> First of all, Google is a shell of the company it used to be. Isn't that squarely at odds with Google's supposed AI prowess? Is the rot really so severe that their advances in AI (including things they've yet to make public) are insufficient to overcome it? Or are the capabilities of Gemini and AI systems in general being oversold?

> Or are the capabilities of Gemini and AI systems in general being oversold?

I pretty much sure that if anyone asked Gemini "Is it good idea to retroactively opt-in new services into for old API keys?" it would suggest it's bad idea. Problem is that no one asked.

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

#133

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

Keys could have certain restrictions [1] such as HTTP Referer, which meant you couldn't just embed a map on your website and charge a different website for the views. Not perfect protection of course - an attacker could spam requests with all the right headers if they wanted to - but it removes one of the big motivations for copying someone else's API key. [1] https://docs.cloud.google.com/api-keys/docs/add-restricti…

I was thinking more maliciously targeting the developer and running up a huge bill than reusing their key for your use

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

#134
post #70

Earlier quoted context omitted.

Seems like they ought to be dedicated security teams monitoring for exactly this: does a key to X give users access to not-X. Even more bizarre is their VDP team not immediately understanding the severity of the issue.

And slow down the time to ship things? The shareholders wouldn't like that.

Those poor poor institutional shareholders…

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

#135

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.

Out of all of the cloud providers, I find Microsoft's authentication stack to be the most legible and stable. Everything else really sucks though.

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

#136

[flagged]

The new code changes from not existing, to existing. Indeed, the key doesn't change. The new capability comes from the new code . It would not be a re-evaluation of risk, because this is a new project. The evaluation of risk is supposed to come at the moment when the new capability is implemented, and consciously tied to an existing key type, which was previously advertised as non-secret.

They're obviously talking about on the client's end, not Google

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

#137
post #47

Earlier quoted context omitted.

2k feels very small considering the number of business sites that embed Google Maps. I guess a lot of those sites use other website building services that handle the Google API keys for them, and/or they're old and untouched enough that no one enabled Gemini on them.

I had the same thought. I guess a lot of those keys may belong to dormant/deleted accounts and only a % of people who have enabled Gemini (presumably it required user action)

[flagged]

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

#138
post #83

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…

[flagged]

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

#139
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.
Post reply on HN