←back to thread

Lost $300 due to an API key leak from "vibe coding" – Learn from my mistake

4 points liulanggoukk | 1 comments | 14 Sep 25 16:16 UTC | HN request time: 0.211s | source

I just learned an expensive lesson and wanted to share it here so others don’t make the same mistake.

I recently lost $300 because of an API key leak. It started with a surprise $200 charge from Google Cloud, and when I looked into it, I found another $100 charge from the day before. Both were for Gemini API usage that I never intentionally set up.

After digging, I discovered the issue: I had hard-coded an API key in a script that was part of a feature I ended up deprecating. The file was only in the codebase for two days, but that was enough for the key to leak. Google actually sent me alerts about unusual activity, but I missed them because they went to a less-frequently-checked email account.

Here’s what I learned:

Never hardcode API keys - Use environment variables or a .env file, even for temporary code.

Set up billing alerts - Google Cloud (and other providers) let you set up alerts for unexpected charges.

Check all linked emails - Don’t ignore notifications, even if they’re sent to secondary accounts.

Don’t rely solely on GitHub’s secret scanning - It’s useful, but renaming variables can bypass it.

This happened while I was experimenting with "vibe coding" (letting AI generate code quickly), but I realized too late that human oversight is still crucial, especially for security.

Hope this helps someone avoid the same costly mistake!

TL;DR: Hard-coded an API key in a deprecated script, key leaked, and I got charged $300. Always use environment variables and set up billing alerts!

1. scarface_74 ◴[15 Sep 25 20:22 UTC] No.45254474[source]▶
You learned the wrong lesson.

You should never specify API keys anywhere in your code or env files for GCP or AWS.

https://cloud.google.com/docs/authentication/application-def...

You still risk checking in your env file.

Doing it the correct way, your config is in your home directory locally far away from your repo and it finds the configuration automatically when running on GCP.

Even better when developing locally is assign environment variables to temporary access keys.

I’m being handwavy because I’m not a GCP guy. But on AWS, you do something similar by using “aws config” locally and using the IAM role attached to the VM, Lambda, etc so you never need to deploy with access keys.

This isn’t meant to be an “AWS does it better comment”. It looks like from my brief research, something similar is also best practice with GCP.