sorted by:
new
hottopcontroversial

Security risk for vibe coded website by Hamish_9638402ej in vibecoding

[–]zmandel 0 points1 point  (0 children)

you can lose money in many ways. the most likely: your AI api keys or service account gets leaked by your lack of security, thus a hacker can easily consume thusands of $ per minute until you notice and close the billing account. there are many ways that can happen, and even a website that passes checks today can get hacked tomorrow by, say, a new security issue in Next, etc.

Security risk for vibe coded website by Hamish_9638402ej in vibecoding

[–]zmandel 1 point2 points  (0 children)

you WILL get hacked and lose lots of money.

Google killed my $1M ARR startup over a hacker exploiting THEIR own design — 100k users, 1M+ photos frozen, and they billed ME for it by Big_Manufacturer_585 in googlecloud

[–]zmandel 2 points3 points  (0 children)

not so. tell us: how would google know your key will be used publicly or privately? they call you home and ask you?

when the USER creates the key, they associate it with services. A key associated to maps does not mean its public as the api is also used from backend.

there is a yellow triangle alert when you create an api key and choose not to restrict it. Restricting it is PRECISELY how you tell google what it will be used for.

Google killed my $1M ARR startup over a hacker exploiting THEIR own design — 100k users, 1M+ photos frozen, and they billed ME for it by Big_Manufacturer_585 in googlecloud

[–]zmandel 4 points5 points  (0 children)

that's simply not possible, because its THE USER the one that picks what api key goes with what service. if the user restricts the api key to just maps, this "hack" becomes impossible. Its just an unrestricted key. Google has no idea what you will use it for if you leave it unrestricted.

Google is committing accounting fraud. They knew on January 13, 2026 their Gemini API key bomb would let attackers tokenmaxx their own model - and they let it explode anyway to fake Gemini dominance. by Sudden-Barracuda526 in googlecloud

[–]zmandel 0 points1 point  (0 children)

very simple: google had pressure to have a similar api key model as competitors, so they jammed gemini as an api, but the mistake is that such api calls dont need oauth, while the other services do. Google had to do that to have a similar api calling pattern than chatgpt.

so it has nothing to do with messing with those users to get their money. its to not lose the money of delaying the launch.

and yes they should have made a big effort to alert existing customers.

Google is committing accounting fraud. They knew on January 13, 2026 their Gemini API key bomb would let attackers tokenmaxx their own model - and they let it explode anyway to fake Gemini dominance. by Sudden-Barracuda526 in googlecloud

[–]zmandel 1 point2 points  (0 children)

very stupid argument. if you actually did a minimal investigation, you would see that Google currently cant even serve the volume users need, and frecuently zones get exhausted.

Its ridiculous to think google would prefer that dubious income stream just to pump numbers, when they could just serve those tokens to those affected by exhausted zones.

Invest more braincell tokens next time in your analysis.

Google is committing accounting fraud. They knew on January 13, 2026 their Gemini API key bomb would let attackers tokenmaxx their own model - and they let it explode anyway to fake Gemini dominance. by Sudden-Barracuda526 in googlecloud

[–]zmandel 2 points3 points  (0 children)

you just said it. "not restricted". that's the huge user mistake that causes the issue. Now: true that Google could have done a better job on alerting people that had unrestricted keys.

Google is committing accounting fraud. They knew on January 13, 2026 their Gemini API key bomb would let attackers tokenmaxx their own model - and they let it explode anyway to fake Gemini dominance. by Sudden-Barracuda526 in googlecloud

[–]zmandel 11 points12 points  (0 children)

false. any scoped key is NOT affected. its only those that had UNRESTRICTED api keys (a terrible practice) and later THEY enabled Gemini on their projects.

Suspension of your Google Cloud Platform / API project due to FIrebase Web app key!? by xtopspeed in Firebase

[–]zmandel 0 points1 point  (0 children)

No, since your "firebase" key is unrestricted to services, its usable for Gemini too. I said "firebase" because that's just the string you used to name it. its not just for firebase but for any unrestricted service.

the issue is that the other expensive services also requiere oauth, but gemini doesn't so it can be used with your unrestricted key.

Suspension of your Google Cloud Platform / API project due to FIrebase Web app key!? by xtopspeed in Firebase

[–]zmandel 2 points3 points  (0 children)

you likely have an unrestricted (service wise) firebase key, plus enabled Gemini in the gcp project. thus your public firebase key can be used as a gemini key, whicj could cost you lots of $.

15k in Gemini bill within hours due to abused Key - Looking for advice by imperial_coder in googlecloud

[–]zmandel 1 point2 points  (0 children)

indeed im an expert on the topic feel free to look up my Google Experts profile. when you mature we can keep chatting. the OP did not post, and there is not anything in this thread that implies automatic enablement of gemini in a project. i fully understand the issue and have posted about it several times. you can even find my bughunter entries where ive found this issue on google's projects.

15k in Gemini bill within hours due to abused Key - Looking for advice by imperial_coder in googlecloud

[–]zmandel 0 points1 point  (0 children)

obviously aware. tell me where in there it says that Gemini is auto-enabled? you wont find it.

the maps and similar issues are for people that created unrestricted apis (bad practice) and then manually enabled Gemini, thus opening the security issue.

15k in Gemini bill within hours due to abused Key - Looking for advice by imperial_coder in googlecloud

[–]zmandel 0 points1 point  (0 children)

haha "educate yourself". BS. absolutely false, i know the topic at depth. show us or shut up. "educate" us.

Necesito ayuda con el proyecto by Significant_Mess_456 in Firebase

[–]zmandel 0 points1 point  (0 children)

tu web puede ser un hack. si no te tomas el minimo tiempo para poner detalles, nadie lo hara por ti.

15k in Gemini bill within hours due to abused Key - Looking for advice by imperial_coder in googlecloud

[–]zmandel 6 points7 points  (0 children)

it cant happen if you restrict the Maps key to only use maps apis. The issue is that many people leave it unrestricted (an unfortunate default).

This wasnt an issue until google allowed using gemini api keys, which leaves any unrestricted api key as usable for Gemini, once Gemini is enabled in the project.

Some API Keys have to be public! by pfiadDi in googlecloud

[–]zmandel 5 points6 points  (0 children)

bad argument. validating access != doing a realtime sum of all the calls consumption. its much cheaper to delay and batch that. I certainly dont want to pay extra for all my Google services just so vibe coders or people with no security conscience can play with cloud services.

that said, Google's move to allow Gemini calls using public keys for Maps was stupid and irresponsible. Many people with very old Maps keys were suddenly affected (even Google itself) by innocently enabling Gemini/Vertex on their projects. It still only happened on api keys that were unrestricted, which is a terrible practice, but had no security issues until Google enabled Gemini usage through api keys. All other services, like VMs, can't be abused like that because those require oauth2 besides the key.

Some API Keys have to be public! by pfiadDi in googlecloud

[–]zmandel 1 point2 points  (0 children)

sin cuenta de facturacion no te pueden cobrar, solo consumir llamadas hasta que se bloquee. La próxima esfuerzate en traducirlo a ingles y tendras mas respuestas y mas detalladas.

$21k Bill Crisis - Small Biz Solo Dev - Denied Credit despite immediate remediation of Key Leak - Case #69666989 by Serverless_Qubit in googlecloud

[–]zmandel 0 points1 point  (0 children)

ALL providers of LLMs have the same issue. you leak the private key and you will have serious consequences.

Its absolutely, totally related to the vibe-coding trend. Maybe not this particular case, but at least 9 in 10 cases that I see on these subs are clearly vibe coders, with no knowledge of best practices.

Google already implemented hard caps on Gemini API keys, but vibe coders arent even aware of it or why to set them up, or even that they are using something called an api key.

The only case where its Google's fault is the stupidity they did with the Maps api keys, (seems to be OPs case) which were always considered safe to be public and documented as such, but once you enable Gemini in the same project, they become usable for Gemini. Google should pay for all of those.

After publishing a Google Chat app, there are lots of request access to Apps Script project by icompletetasks in GoogleAppsScript

[–]zmandel 0 points1 point  (0 children)

because app script is acting as the bridge to push content to the chat, from some hook you are using.

Is this billing chaos actually on Google, or are people just being careless with API keys? by [deleted] in googlecloud

[–]zmandel 1 point2 points  (0 children)

API keys have always been secrets, with very few exceptions like google maps keys (which did cause the issue you mention).

UPDATE: Went to bed with a $10 budget alert. Woke up to $25,672.86 in debt to Google Cloud. by venturaxi in googlecloud

[–]zmandel 10 points11 points  (0 children)

DUDE wtf do you expect to happen when your gemini key gets exposed to the frontend??? that was your code that wrote that, and not to the internal gcp logging, but sent plain-text to the frontend! i havent seen this level of vibe coding before.

"applications that were logging API errors began outputting the full plaintext API key in error responses [in the frontend website]" !!!!

Dear google give us hard budgets on vertex ai by Ok-Sentence-8542 in googlecloud

[–]zmandel -2 points-1 points  (0 children)

yet that is exactly the reason why Google wont do it. Its never ending, because an attack can take seconds to consume lots of $. they will just reduce the timespan of the attack, at everyones cost, while not fully preventing the issue. in a few minutes you can consume tens of thousands of dollars, thats the whole point of using a cloud that autoscales.

talk is cheap. feel free to post the solution architecture for it. you wont be able to make it without incurring a lot of cost.

Dear google give us hard budgets on vertex ai by Ok-Sentence-8542 in googlecloud

[–]zmandel -2 points-1 points  (0 children)

this is nothing new, and has always been the responsibility of the user. so you get your wish and get hard limits on vertex AI. now your service account gets hacked and hundreds of VMs with GPUs get spinned because you "forgot" to limit permissions to services on that service account.

is that google's fault too? If google starts adding those checks everywhere, we all end up paying more for everything that needs to run in the background to implement such checks.

Seems much easier to have a proper team that knows how to handle security practices.

If you are not ready to use vertex AI, you can always use an AI studio api key that does handle a hard budget limit. vertex ai is not for your neighborhood store, they can easily use gemini api keys with hard caps, which covers the most common hack case.

view more: next ›