API Key Security: Best Practices for Developers
About 8 min read
Published: Last updated:
API keys and secrets are the credentials that grant programmatic access to services and data. A leaked API key can lead to unauthorized access, data breaches, and unexpected charges. It is not unusual for an AWS access key accidentally committed to a public GitHub repository to be discovered by bots within minutes and abused to run up a costly bill. According to GitGuardian's State of Secrets Sprawl 2026 report, about 28.65 million new secrets were detected in public GitHub commits during 2025, roughly 34 % more than the year before. This article explains, from a developer's point of view, the risks of API key exposure and practical ways to manage keys safely using environment variables and a secrets manager.
What Should You Do First?
Improve your API key management in the following order of priority. If you are just starting out, add .env files to .gitignore and move any hardcoded keys in your source code into environment variables. At an intermediate level, enable git-secrets or GitHub secret scanning so that leaks are detected automatically. At an advanced level, adopt AWS Secrets Manager or HashiCorp Vault and configure automatic key rotation.
Why API Key Leaks Are Dangerous
Unlike passwords that protect individual user accounts, API keys often grant broad access to entire services, databases, or cloud infrastructure. A single leaked key can create a critical vulnerability that compromises an entire system.
Automated bots continuously scan public repositories for exposed credentials. Once a key is found, attackers can exploit it within minutes to spin up cryptocurrency miners, exfiltrate data, or launch attacks on other systems. Supply chain attacks that inject malicious code into legitimate libraries are another route to API key theft: when the library runs, the injected code reads environment variables and configuration files and sends any keys it finds to an external server.
Common Causes of API Key Exposure
Hardcoding in Source Code
Embedding API keys directly in source code is among the main causes of leaks. Even if the repository is private, keys in code can be exposed through code sharing, screenshots, or repository access changes. Once a key has been committed to Git history, it remains in that history even after you delete it from the code, so fully removing it requires rewriting history with `git filter-branch` or BFG Repo-Cleaner.
Committing .env Files
Environment files containing secrets are sometimes accidentally committed when .gitignore is not properly configured. Always verify that sensitive files are excluded from version control. Set up .gitignore correctly at the start of a project and confirm that files such as .env, .env.local, and .env.production are reliably excluded.
Client-Side Exposure
API keys embedded in frontend JavaScript are visible to anyone who inspects the page source. Keys that grant write access or access to sensitive data must never be used in client-side code. An exposed key can serve as a backdoor into your system for attackers.
Best Practices for Secure Key Management
Environment Variables
Store API keys in environment variables rather than in code. Use .env files for local development and configure environment variables through your deployment platform for production. Always add .env files to .gitignore, and include a template file such as .env.example (key names only, with no values) in the repository so that team members can see which environment variables are required.
Secret Managers
For production environments, use dedicated secret management services like AWS Secrets Manager, HashiCorp Vault, or Google Secret Manager. These provide encryption at rest, access control, and automatic rotation. Automatic rotation in particular limits how long a key stays valid, which minimizes the blast radius if a leak does occur. With AWS Secrets Manager, the official AWS pricing page (as of September 2026) lists $0.40 per secret per month, and at that cost the service can substantially reduce the risk and operational burden of managing keys by hand (check that page for current rates).
Key Rotation
Regularly rotate API keys to limit the window of exposure if a key is compromised. Set the rotation interval according to how critical each key is: within 90 days for important production keys and within 180 days for development keys is a reasonable guideline. Manual rotation invites human error, so automate it wherever you can. One caveat: if you invalidate the old key the instant you rotate, your service may go down temporarily depending on when the deployment lands. The safe procedure is to run the old and new keys in parallel for a period, confirm that every system has switched to the new key, and only then invalidate the old one.
Least Privilege Principle
Grant API keys only the minimum permissions needed for their specific use case. Avoid using master keys or admin-level credentials in application code. Use AWS IAM policies or Google Cloud IAM roles to implement fine-grained access control. The principle of least privilege is the most fundamental security principle in API key management.
Generating Strong API Keys with Passtsuku.com
When you need to generate custom API keys or secrets, Passtsuku.com provides cryptographically secure random strings. Set the length to 32 characters or more with all character types enabled for maximum entropy.
For generating multiple keys at once, use the bulk generation feature. Each key will be unique and cryptographically random, suitable for different services and environments.
Detecting Leaked Keys
Use tools like git-secrets, truffleHog, or GitHub's built-in secret scanning to detect accidentally committed credentials. Set up pre-commit hooks to prevent secrets from being committed in the first place. If a key does leak, invalidate it immediately and issue a new one. It is also important to review your access logs to confirm whether the leaked key was used for unauthorized access. See also how to respond when a data breach occurs.
Take Action Now
- Verify that .gitignore includes .env, .env.local, and .env.production, and add them if missing
- Search for hardcoded API keys in source code and migrate any found to environment variables
- Generate random strings of 32+ characters with Passtsuku.com for use as custom API keys or secrets
- Enable GitHub's secret scanning feature to automatically detect leaks
- Set up a rotation schedule of 90 days or less for critical production keys
Frequently Asked Questions
- What should I do if I accidentally hardcoded an API key in source code?
- Immediately revoke the key and issue a new one. Since it remains in Git history, use git filter-branch or BFG Repo-Cleaner to rewrite history. Manage the new key via environment variables.
- How often should I rotate API keys?
- Critical production keys should be rotated within 90 days, development keys within 180 days. Use AWS Secrets Manager or similar tools to automate rotation and reduce manual management risk.
- What if I need to use an API key in frontend code?
- Never use keys with write access or sensitive data access in frontend code. Relay requests through a backend API instead. Even for public API keys, set HTTP referrer restrictions and usage limits.
Was this article helpful?