How to Securely Store API Keys and Secrets

· · Daniel A

How to Securely Store API Keys and Secrets

To securely store API keys, use environment variables for local development and dedicated secrets managers like AWS Secrets Manager for production. For personal reference and developer snippets, use a client-side encrypted notes app like SimplyBoard to ensure your secrets are never stored in plain text or accessible by third parties.

To securely store API keys and secrets, you must move them out of your source code and into dedicated environments like environment variables, secrets managers (AWS Secrets Manager, HashiCorp Vault), or client-side encrypted notes apps for personal reference. Never commit secrets to version control or store them in unencrypted text files.

The convenience of having a key ready to paste is often the enemy of security. Whether you are a solo developer or part of a large engineering team, the way you handle credentials determines the "blast radius" of a potential leak. A single exposed AWS key can result in tens of thousands of dollars in unauthorized compute charges within hours, while a leaked Stripe key can lead to catastrophic financial data breaches.

The Cardinal Sins of Secret Management

Before looking at the solutions, we must acknowledge the common habits that lead to compromise. If you are doing any of the following, your infrastructure is at risk:

  • Hardcoding keys in source code: Even in private repositories, this is a risk. Employees leave, permissions change, and "private" repos are often one configuration error away from becoming public.
  • Committing secrets to version control: Once a secret is in your Git history, it is there forever. Even if you delete the line in a subsequent commit, the key remains in the repository's history and can be easily extracted.
  • Storing keys in unencrypted text files: Files like notes.txt or keys.json sitting on your desktop are vulnerable to any local malware or unauthorized physical access.
  • Sharing via Slack, Discord, or Email: These platforms are not designed for secret storage. They index your messages, and anyone with access to the workspace (or a compromised account) can search for "API_KEY" and find a goldmine.
  • Pasting keys in public documentation or screenshots: It sounds obvious, but "accidental exposure" via screen sharing or documentation screenshots remains a leading cause of credential leaks.

Why the Risk is Immediate

The threat is not theoretical. Bots constantly scan public repositories for exposed secrets, and once found, these keys can be used for unauthorized access, data breaches, or financial fraud. Research has shown that secrets committed to GitHub are often detected and exploited by malicious actors within minutes · sometimes seconds · of the push.

The impact varies by service:

  • Cloud Providers (AWS/GCP/Azure): Used for crypto-mining, which can rack up massive bills in a single night.
  • Payment Processors (Stripe/PayPal): Used to process fraudulent transactions or export customer data.
  • AI Services (OpenAI/Anthropic): Used to fuel third-party applications on your dime, exhausting your rate limits and credits.

Best Practices for Production Environments

For applications running in production, you need a system that provides "just-in-time" access or secure injection of secrets.

1. Use a Dedicated Secrets Manager

Tools like AWS Secrets Manager, HashiCorp Vault, or Google Cloud Secret Manager are the gold standard. These services provide:

  • Encryption at Rest: Your secrets are encrypted using hardware security modules (HSMs).
  • Programmatic Access: Your application fetches the key at runtime via an API or SDK, meaning the key never lives on a disk.
  • Automatic Rotation: You can configure these tools to automatically change your passwords and API keys every 30, 60, or 90 days without manual intervention.

2. Environment Variables

In modern cloud environments (like Heroku, Vercel, or Docker), secrets are often injected as environment variables. This keeps them out of the codebase. However, ensure that your environment is not logging these variables to stdout or error logs, as that creates a new leak vector.

Best Practices for Development Environments

Local development requires a different balance of speed and security.

The .env File Strategy

Most frameworks support .env files. These allow you to define variables locally that your app loads at runtime.

  • Always gitignore your .env files: Your .gitignore should explicitly include .env, .env.local, and any other variations.
  • Use a .env.example: Commit a template file (e.g., STRIPE_KEY=your_key_here) so other developers know which variables they need to set up without seeing the actual values.

For Personal Reference: The Encrypted Notes Solution

Developers often need to store "meta-secrets" · the keys to their personal tools, snippets of configuration, or credentials for services they are currently testing. Storing these in a standard notes app is a massive privacy risk because most popular note-taking apps can read your data.

This is why we built SimplyBoard. It serves as a secure, client-side encrypted vault for the information that doesn't belong in a production secrets manager but is too sensitive for a plain text file.

Why SimplyBoard is the Best Note App for Developers

  • Zero-Knowledge Encryption: We use AES-256-GCM encryption in your browser. The key is derived from your password using Argon2id. We cannot read your notes, and we cannot reset your password to access your content.
  • Instant Search: Our instant fuzzy search allows you to find a specific key or snippet across multiple workspaces in milliseconds.
  • Offline-First: Because SimplyBoard uses an encrypted IndexedDB cache, you can access your keys even when you have no internet connection. It syncs automatically once you are back online.
  • Developer-Friendly: It is keyboard-first and supports Markdown, making it the perfect Obsidian alternative for those who want privacy without the complex vault setup.

Implementing Key Rotation and Scoping

Security is not a "set it and forget it" task. You must actively manage the lifecycle of your secrets.

Limit the Scope (Principle of Least Privilege)

When generating an API key, never give it "Full Access" or "Admin" permissions if it only needs to read one specific database table. Most modern APIs (like AWS IAM or GitHub Fine-grained PATs) allow you to restrict a key to specific actions and resources.

Regular Rotation

Rotate your keys regularly. If a key has been exposed (or you suspect it might have been), rotate it immediately. Most services allow you to have two active keys simultaneously, which lets you "roll" the key:

  1. Generate a new key.
  2. Update your application to use the new key.
  3. Verify the new key is working.
  4. Deactivate the old key.

A Security Checklist for Developers

  1. Audit your Repos: Use tools like git-secrets or trufflehog to scan your commit history for existing leaks.
  2. Move to Secrets Managers: Transition production credentials out of config files and into a managed service.
  3. Secure your Personal Notes: Move your "scratchpad" secrets out of Apple Notes or Google Keep and into a private, encrypted environment like SimplyBoard.
  4. Enable MFA: Ensure that the accounts generating these API keys are protected by Multi-Factor Authentication.
  5. Monitor Usage: Check your API provider's dashboard for unusual spikes in usage, which often signal a compromised key.

By following these practices, you reduce your vulnerability and ensure that even if one part of your system is compromised, your most sensitive credentials remain protected.

· The SimplyBoard Team

Frequently asked questions

What is the most secure way to store API keys in a web application?

Never hardcode API keys in source code or commit them to version control. Instead, use environment variables stored in a .env file (which must be added to your .gitignore) or use a dedicated secrets management service like HashiCorp Vault or AWS Secrets Manager to inject keys at runtime.

What should I do if I accidentally commit an API key to GitHub?

If an API key is leaked, you must revoke it immediately through the provider's dashboard. After revocation, generate a new key, update your application's environment variables or secrets manager, and audit your logs for any unauthorized activity that occurred while the key was exposed.

Are environment variables secure enough for production secrets?

Environment variables are safer than hardcoding because they keep secrets out of the codebase. However, they can still be exposed through server logs or process dumps. For high-security production environments, a dedicated secrets manager is preferred over simple environment variables because it offers better auditing and rotation features.

Is it safe to store API keys in a note-taking app?

Standard notes apps like Apple Notes or Google Keep often store data in a way that the provider can access. For sensitive developer data, use a client-side encrypted app like SimplyBoard. This ensures keys are encrypted locally on your device before being synced, meaning only you hold the decryption key.

Why is API key rotation important for security?

Key rotation is the practice of periodically replacing old API keys with new ones. This limits the amount of time a leaked key is useful to an attacker. Many organizations rotate keys every 30 to 90 days, or immediately upon any change in personnel who had access to the keys.

How does the Principle of Least Privilege apply to API keys?

The Principle of Least Privilege means giving an API key only the minimum permissions it needs to perform its task. For example, if a key only needs to upload files to an S3 bucket, it should not have permission to delete files or list other buckets in the account.

Related guides