[deleted]
Google API keys weren't secrets, but then Gemini changed the rules
81–90 of 326 posts
Re: Google API keys weren't secrets, but then Gemini changed the rules
#82Earlier quoted context omitted.
Maps keys are always public in js on the website (but locked to use on certain domains). That’s how they work.
It is not actually locked to a site is just based off the host header. Which is public information an attacker can use to make the requests.
Is there a way to use Google maps apis on the web without exposing the key?
Re host header seems an odd way for Google to do it, surely they would have fixed that by now? I guess not a huge problem as attackers would have to proxy traffic or something to obscure the host headers sent by real clients? Any links on how people exploit this?
Re: Google API keys weren't secrets, but then Gemini changed the rules
#83In 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...
Re: Google API keys weren't secrets, but then Gemini changed the rules
#84Earlier quoted context omitted.
How do you know that this blog post was written by ChatGPT?
It feels generated to me too. It’s this: When you enable the Gemini API (Generative Language API) on a Google Cloud project, existing API keys in that project (including the ones sitting in public JavaScript on your website) can silently gain access to sensitive Gemini endpoints. No warning. No confirmation dialog. No email notification. Specifically, the last bit - “No warning. No confirmation dialog. No email notif…
I think there's a lot more than just that, but I think part of the problem is that you just get an uncanny valley feeling. All of the phrases and rhetorical tricks that these tools use are perfectly valid, but together they feel somehow thin?
That said, some specific things that feel very AI-y are the mostly short, equally-sized paragraphs with occasional punchy one-sentence paragraphs interspersed between them; the use of bold when listing things (and the number of two-element lists); there are a couple of "it's not X, it's Y"-style statements; one paragraph ends with an "they say it's X, but it's actually Y" construct; and even the phrasing of some of the headings.
None of these are necessarily individually tells of AI writing (and I suspect if you look through my own comments and blog posts on various sites, you'd find me using many of the same constructs, because they're all either effective rhetorically, or make the text clearer and easier to understand). But there's something about the concentration of them here that feels like AI - the uncanny valley feeling.
I would put money on this post at least having gone through AI review, if not having been generated by AI from human-written notes. I understand why people do that, but I also think it's a shame that some of the individual colour of people's writing is disappearing from these sorts of blog posts.
Re: Google API keys weren't secrets, but then Gemini changed the rules
#85Earlier 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.
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.
That's how you slow down development to a crawl
Re: Google API keys weren't secrets, but then Gemini changed the rules
#86This 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...
Re: Google API keys weren't secrets, but then Gemini changed the rules
#87Earlier quoted context omitted.
It is not actually locked to a site is just based off the host header. Which is public information an attacker can use to make the requests.
Is there a way to use Google maps apis on the web without exposing the key? Re host header seems an odd way for Google to do it, surely they would have fixed that by now? I guess not a huge problem as attackers would have to proxy traffic or something to obscure the host headers sent by real clients? Any links on how people exploit this?
Google's own recommended practices https://developers.google.com/maps/api-security-best-practic...
Re: Google API keys weren't secrets, but then Gemini changed the rules
#88What'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)
Gemini API is not enabled by default, a project owner has to go explicitly enable it. The problem described here is that developer X creates an API key intended for Maps or something, developer Y turns on Gemini, and now X's key can access Gemini without either X or Y realizing that this is the case. The solution is to not reuse GCP projects for multiple purposes, especially in prod.
You are wrong that increasing projects have no cost; many services have project based costs (Cloud Armour rules cannot be used cross project at the base tier), many services (mostly observeability) degrade significantly cross project, the Google Cloud Console _sucks_ cross project.
You are also wrong in saying there are no projects that could reasonably have a safe api key made unsafe by this exploit.
One example, a service that has firebase auth must publish the key (Google's docs recommend). Later, you add gen ai to that service, managing access using IAM/service accounts (the proper way). You've now elevated the Firebase Auth Key to be a Gemini key. Really undeniably poor from Google.
Re: Google API keys weren't secrets, but then Gemini changed the rules
#89What'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)
Gemini API is not enabled by default, a project owner has to go explicitly enable it. The problem described here is that developer X creates an API key intended for Maps or something, developer Y turns on Gemini, and now X's key can access Gemini without either X or Y realizing that this is the case. The solution is to not reuse GCP projects for multiple purposes, especially in prod.
The problem is Google explicitly stating that those API keys are not secret and should be public, which indeed was true until Gemini came around.
Re: Google API keys weren't secrets, but then Gemini changed the rules
#90Earlier quoted context omitted.
Is there a way to use Google maps apis on the web without exposing the key? Re host header seems an odd way for Google to do it, surely they would have fixed that by now? I guess not a huge problem as attackers would have to proxy traffic or something to obscure the host headers sent by real clients? Any links on how people exploit this?
Google's own recommended practices https://developers.google.com/maps/api-security-best-practic...
It would be helpful if you answer the question about web api usage, most of that is not relevant.
The only suggestion I see there from a quick skim that would avoid the above is for customers to set up a google maps proxy server for every usage with adds security and hides the key. That is completely impractical suggestion for the majority of users of embedded google maps.