API Key Security Best Practices Every Developer Should Know.

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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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