DEV Community: affan

Why Developers Are Bad at Securing Their Own API Keys

affan — Sun, 15 Mar 2026 17:06:13 +0000

We spend hours making our apps secure for users.

HTTPS everywhere. Encrypted databases. Two factor auth. Rate limiting.

Then we store our own API keys in a Notion doc shared with the whole team.

The irony is real and it costs developers and companies thousands of dollars every year in breaches, leaked infrastructure, and unauthorized charges.

Why This Happens

When you're building fast, security shortcuts feel harmless. You tell yourself:

"I'll fix this later"

"It's just a dev key"

"Nobody will find this Notion link"
But later never comes. And dev keys often have the same permissions as
prod keys. That's the real problem.
The truth is most developers treat API keys as an afterthought. You're focused on shipping features, fixing bugs, hitting deadlines. Security feels like a separate concern you'll deal with eventually. But API keys are not an eventually problem. They're a right now problem.

The Real Cost of a Leaked API Key

Before we get into mistakes, let's talk about what actually happens when a key gets exposed.

AWS keys found by bots on GitHub have resulted in bills of $50,000 or more within hours. These bots are automated and run 24/7 scanning every public commit for patterns that look like API keys.

Stripe keys can be used to issue fraudulent refunds or pull customer data. OpenAI keys get used to run expensive prompts at your expense. Twilio keys get used to send spam at scale billed to your account.

The damage is not just financial. If customer data is accessed through an exposed key you're looking at potential GDPR violations, angry users, and
reputation damage that's hard to recover from.

The Most Common Mistakes Developers Make

API keys in .env files committed to GitHub
This is the single most common mistake. You set up your project, create a .env file, add your keys, and forget to add .env to your .gitignore. One push and it's public. Even if you delete the file in the next commit, the key is still in your git history forever.
Keys shared over Slack and never rotated
Your teammate needs the Stripe key. You paste it in Slack. Now that key lives in your Slack history accessible to anyone in that channel, any admin, and any third party app connected to your Slack workspace. And it never gets rotated so it stays exposed indefinitely.
Same key used across dev and production
This one feels convenient until it isn't. If your dev environment gets breached, your production app is compromised too. Always use separate keys for each environment.
No record of which keys exist or where they are
Ask yourself right now: how many API keys does your project use? Where is each one stored? When was each one last rotated? Most developers can't answer these questions and that's a serious risk.
Keys never rotated after a team member leaves
When someone leaves your team they take their memory of where keys are stored. If they still have access to those keys anywhere, you have a security gap until you rotate everything.
What Actually Helps
Start treating your API keys like passwords. You would never store passwords in a Notion doc. You would never share passwords over Slack. You would never use the same password everywhere.
Same rules apply to API keys.
Use environment variables everywhere. No keys in code, no keys in config files that get committed. Every key lives in environment variables set at the deployment level.
Add .env to .gitignore before you write a single key. Do this first thing when you set up a project, not after.
Create separate keys for dev, staging, and production. Every environment should have its own set of keys with only the permissions that environment
actually needs.
Keep all your keys in one organized secure place. This is the part most developers skip and it's the most important habit to build. When you know exactly where every key lives you can rotate them quickly, audit access, and respond fast if something gets exposed.
Rotate keys regularly and immediately after any team changes. Treat key rotation like changing passwords. Do it on a schedule and always do it when someone leaves.

I got tired of managing keys across scattered places so I built Keydock, a simple secure vault for all your API keys with zero knowledge encryption so even the server can't read your keys.
Try it free at keydock.cloud

API Key Security Best Practices Every Developer Should Know.

affan — Thu, 12 Mar 2026 23:09:55 +0000

You probably have API keys scattered everywhere right now.
.env files. Notion docs. Slack messages. Maybe even a sticky note
somewhere.

And honestly most developers do. It happens gradually. One project becomes two becomes ten and suddenly you have OpenAI keys, Stripe keys, AWS keys, Twilio keys, and GitHub tokens living in six different places with no clear ownership or rotation schedule.

One mistake can expose your entire app to the world. Here's what you should actually be doing and why each practice matters.

Never Commit API Keys to GitHub
This is the most common mistake and the one with the fastest consequences.
GitHub has automated bots that scan every public commit for patterns that look like API keys. They run 24/7. By the time you notice you pushed a key, someone has already grabbed it. AWS keys have led to bills of $50,000 or more within a single day this way.
How to fix it: Add .env to your .gitignore before you create it. Not after, before. Make this the first thing you do when setting up any project. Also consider using a tool like git-secrets that blocks commits containing credential patterns.
Even if you're working on a private repo, get into this habit. Private repos can become public, get forked, or have their access compromised.
Never Hardcode Keys in Your Codebase
This one seems obvious but happens constantly, especially when you're moving fast and just want to test something quickly.
The problem is hardcoded keys end up in version history forever even after you delete them. Anyone with access to your repo can run git log and find the key. Anyone who ever cloned the repo has it locally.
How to fix it: Always use environment variables. Every language and framework has a way to read from environment variables. There is no situation where hardcoding a key is the right move.
Separate Dev and Production Keys
Your development keys and production keys should never be the same string.
If your dev environment gets compromised, maybe through a dependency vulnerability or a misconfigured server, your production app stays completely safe if you're using separate keys. If they're the same key, one breach means everything is exposed.
How to fix it: Create separate API keys for each environment in every service you use. Most services let you create multiple keys with different permission levels. Take 5 minutes to set this up properly from the start.
Use the Principle of Least Privilege
Every API key should only have the permissions it actually needs. Nothing more.
If your key only needs read access to a service, don't create it with write access too. If your key only needs to access one specific resource, don't give it access to everything.
This limits the blast radius if a key gets exposed. An attacker with a read-only key can see data but can't delete it, write to it, or escalate their access.
How to fix it: When creating API keys, go through the permission settings carefully. It takes an extra few minutes but dramatically reduces your risk exposure.
Rotate Your Keys Regularly
Keys are like passwords. The longer they stay unchanged the more risk you carry, even if you've never had a breach.
You don't know who has seen your key over time. Old team members, contractors, third party tools, services you integrated and then stopped using. Regular rotation cleans all of that up.
How to fix it: Rotate keys every 90 days as a baseline. Rotate immediately after any of these events: an employee or contractor leaves, a key gets accidentally exposed anywhere, you stop using an integration, or you suspect any kind of breach.
Know Where Every Key Lives
If someone asked you right now to list every API key your project uses and where each one is stored, how long would it take you to answer?
If it's more than a few seconds you have a visibility problem. You can't protect what you can't see. You can't rotate what you can't find. You can't revoke access to what you don't know exists.
How to fix it: Keep all your keys in one organized secure place. A proper secrets manager gives you a single source of truth for every key, who has access to it, when it was last rotated, and which service it belongs to.
Have a Response Plan for Exposed Keys
Most developers wait until a key gets exposed to figure out what to do. By then it's too late.
Know in advance: which keys are most critical, how to revoke and regenerate each one, and who needs to be notified if a key is compromised.
How to fix it: Take 30 minutes to document your key rotation process for each service you use. Store that documentation somewhere accessible so you can act fast when you need to.

I learned most of this the hard way across multiple projects with dozens of API keys scattered everywhere. That's why I built Keydock, a simple secure vault to store and manage all your API keys with zero knowledge AES-256-GCM encryption.

Try it free at keydock.cloud