How I Dealt with an Exposed API Key on GitHub

Because of this, hackers or automated crawling systems were able to find and use my API key. As a result, 145 API calls were made without my permission.

Some people might say that this is not a big deal. Fortunately, I found this issue after 13 hours it happens. I guess they use lots of api keys from others like distribute system. Since so, the cost charged to me was so small.

Still, it was a serious security mistake, and I learned an important lesson from it.

So, why did it happends?

I used to use AI tools to implement my small project ideas. And yes, that was part of the problem.

The project repository is here: https://github.com/LeeHan20/CLiCK

The way I usually managed my environment variables was simple. The AI would generate a .env.example file, and then I would copy its contents into my actual .env file.

However, this workflow created a serious risk. At some point, the AI treated .env.example as if it were a place to store real API keys. Since .env.example was not included in .gitignore, it was tracked by Git.

There was another problem as well. When I ran my script, the API key was required, so I pasted the key into the terminal before starting the script. The AI then read that key from the terminal context and inserted it into .env.example.

Because the AI was doing most of the coding for me, I usually only reviewed the code itself. I did not notice that a real API key had been written into .env.example.

After finishing my work, I pushed the commit to the remote GitHub repository. That was when the disaster happened.

After I Discovered the Disaster

I discovered the issue through Google AI Studio. On that day, I had a certification exam, so I had not made a single API call myself. However, when I checked the usage dashboard, I found that 145 API calls had already been made.

Another strange thing was that the calls were made using Gemini 3 Flash, a model I do not normally use because it is expensive. That made it clear that someone else, or some automated system, had found and used my exposed API key.

The first thing I did was fix my .gitignore file. Then, using my local terminal, I removed all commit history that contained the real API key in .env.example.

After that, I deleted all of the exposed API keys. I also issued new API keys for my other projects and replaced the old ones separately to make sure the same key was not reused across multiple projects.

Conclusion

Through this experience, I realized that I should not blindly trust code generated by AI. Even if the code works, I still need to carefully review what has been changed, especially when it involves configuration files, environment variables, or anything related to security.

This incident also made me feel that security threats are not just theoretical. I had heard many times that exposed API keys can be abused, but this was the first time I experienced it directly. Seeing actual API calls made with my key showed me how quickly automated systems can find and exploit leaked secrets.

Although it was a stressful experience, I think it was also a valuable security lesson. It reminded me that even a small mistake in a personal project can lead to a real security problem.

I hope other people do not make the same mistake I did. Before pushing code to GitHub, always check whether any secrets, API keys, or sensitive files are included in your commits.