OWASP API Key Management Best Practices

Store API keys outside source code, restrict their permissions, monitor use, and revoke exposed credentials promptly. Use a secret store for ongoing access and an encrypted one-time link when a human handoff is necessary.

By the SnapPwd team · Updated October 7, 2026

This guide applies OWASP secrets management guidance to API keys. We build SnapPwd, a one-time delivery tool. This is our implementation guidance, not an OWASP endorsement or a security audit.

OWASP-Aligned API Key Security: Storage, Rotation & Monitoring

OWASP-aligned API key management comes down to four recommendations: store keys securely, rotate them on a schedule, monitor usage, and respond fast to leaks. Use this table as a quick reference for secure storage, rotation, monitoring, and incident response.

Area	Recommendation
Secure Storage	Keep keys out of source code and git. Load runtime keys from a secrets manager or platform secret store, and keep local keys in an ignored `.env` file or password manager.
Rotation	For planned rotation, create a replacement, update consumers, verify, then revoke the old key. For a leaked key, revoke promptly and follow incident response instead of waiting for a routine rollout.
Monitoring	Enable provider usage logs, alert on anomalous traffic or unexpected source locations, and track which people and services use each key.
Incident Response	Treat any leaked key as compromised. Revoke it, deploy a scoped replacement, audit recent usage in provider logs, and record the event in your key inventory.

Why API Key Security Matters

An exposed API key can let someone use the permissions granted to that credential. Review the provider's restrictions and monitoring controls; Google Cloud's API key guidance describes restrictions, isolation, and rotation for its APIs.

Common Mistakes to Avoid

Hardcoding in Source Code

Never embed API keys directly in your code. Keys in source files end up in version control, build artifacts, and can be extracted from compiled applications.

Committing to Git

Deleting a key from the latest file does not remove it from earlier commits or existing clones. Revoke an exposed key before planning repository cleanup.

Sharing via Chat or Email

Raw keys pasted into messages can be copied, forwarded, or retained according to workspace and backup policies. Use approved secret storage or an encrypted handoff instead.

Using the Same Key Everywhere

Reusing API keys across environments (dev, staging, prod) or services increases blast radius if one key is compromised.

Security Best Practices

Keep Runtime Secrets Out of Source Code

Load runtime keys from an approved secret store. Environment variables are a delivery mechanism, not encrypted storage; logs and process dumps can expose them.

Use .env files for local development (add to .gitignore)
Use platform secrets management for production
Never log environment variable values

Implement Secret Rotation

Regularly rotate API keys to limit the impact of potential exposure. Automated rotation reduces the window of vulnerability if a key is compromised.

Set up automatic key rotation schedules
Ensure your app can handle key updates gracefully
Allow brief overlap only for planned rotation, not an exposed key

Apply Least Privilege

Create API keys with only the permissions needed for their specific use case. Avoid using admin or full-access keys when limited permissions suffice.

Create separate keys for different services
Use read-only keys when writes aren't needed
Restrict keys to specific IP ranges or domains

Use a Secrets Manager

Enterprise teams should consider dedicated secrets management solutions that provide encryption, access control, audit logging, and rotation.

HashiCorp Vault, AWS Secrets Manager, Azure Key Vault
Centralized access control and audit trails
Automatic secret injection into applications

Monitor and Audit Access

Enable logging for API key usage to detect unusual patterns. Set up alerts for suspicious activity like requests from unexpected locations.

Review API usage logs regularly
Set up anomaly detection alerts
Track which team members access which secrets

API Key Exposure Prevention

API key exposure prevention starts before a key is created. Use scoped credentials, keep keys out of source code, avoid persistent chat history, and rotate keys as soon as exposure is suspected. Treat Slack, email, CI logs, browser screenshots, and public issue trackers as places where secrets should never appear.

Prevent Leaks

Add secret scanning, keep `.env` files in `.gitignore`, and block keys from entering repos, tickets, and logs.

Limit Blast Radius

Use separate API keys for each environment and permission scope, then restrict IPs, domains, or resources when available.

Respond Quickly

Revoke leaked keys, deploy replacements, audit recent usage, and notify affected owners before restoring normal access.

How to Store API Keys Securely

The safest API key storage option depends on who needs the key. Applications should load keys from a secrets manager or platform secret store. Developers should keep local keys in ignored `.env` files or a password manager, then use a secure .env file sharing workflow when a teammate needs local setup values.

Environment Variables

Local development and simple runtime configuration

Use `.env` files only for local development, keep them out of git, and use separate values for development, staging, and production.

Platform Secrets

Hosted apps on Vercel, Netlify, Heroku, or cloud platforms

Store production API keys in the platform's encrypted secrets or environment variable store instead of checking files into the repo.

Secrets Manager

Teams that need access control, audit logs, and rotation

Use tools like AWS Secrets Manager, Google Secret Manager, Azure Key Vault, Doppler, Infisical, or Vault for centralized key management.

Password Manager

Human access to shared non-runtime credentials

Store keys people need to retrieve manually in a team password manager, then deliver initial access through a one-time link.

Are Environment Variables Enough?

An ignored local .env file is still plaintext on disk. Restrict access to the machine and keep production secrets in your approved secret store. OWASP notes that environment variables can appear in logs or dumps; they do not provide encryption by themselves.

In Next.js, never give a secret a NEXT_PUBLIC_ prefix: those values are bundled into browser JavaScript. Read private keys in server-side code and return only the result the client needs. Our environment variable security guide covers local setup and deployment.

API Key Management Best Practices for Teams

API key management is an ownership problem as much as a storage problem. Teams need a repeatable process for creating, storing, sharing, rotating, and revoking every credential.

Assign every API key an owner, purpose, environment, and rotation date.
Create separate keys per app, service, environment, and teammate when the provider supports it.
Prefer scoped keys over broad admin keys, especially for CI and contractor workflows.
Keep an inventory of active keys so offboarding and incident response are not guesswork.
Document the secure handoff workflow for local `.env` setup and temporary access.

API Key Management Checklist

Strong API key management gives every credential a lifecycle. Use this checklist when you create a new key, grant team access, or review an existing service account.

Inventory every API key

Track provider, owner, environment, permission scope, storage location, last rotation date, and revocation path for each key.

Separate runtime and human access

Applications should read keys from a secrets manager. Humans should receive keys through one-time delivery, then move them into a password manager or local ignored `.env` file.

Use scoped, per-service keys

Generate separate keys for CI, staging, production, contractors, and local development so one leaked key has a limited blast radius.

Monitor usage and rotate on events

Review provider logs, alert on unusual traffic, and rotate keys after team changes, vendor handoffs, repository leaks, or suspicious requests.

API Key Rotation and Leak Response

If an API key appears in git, chat, email, logs, or a public paste, treat it as exposed and revoke it promptly at the provider. Notify the service owner, issue a scoped replacement, restore consumers, and review usage. Containment may interrupt service; use your incident procedure rather than leaving a known leaked key active.

OWASP recommends immediate revocation of exposed keys. GitHub also puts revocation or rotation before repository cleanup. Deleting a message or rewriting history cannot invalidate copies.

Planned Rotation When No Exposure Is Suspected

Create the replacement key

For a planned rotation without suspected exposure, generate a scoped replacement so apps and developers have a migration path.

Update storage first

Put the new value in your secrets manager, platform environment variables, password manager, or ignored local `.env` file.

Redeploy and verify

Restart services, confirm successful requests with the new credential, and check logs without printing the key value.

Revoke and audit

Disable the old key after verifying the replacement, review provider logs, and record the owner, scope, and next rotation date in your key inventory.

Quick Reference: Do's and Don'ts

Do

Store keys in environment variables or secrets managers
Use different keys for development, staging, and production
Rotate keys regularly and after any suspected exposure
Restrict key permissions to only what's needed
Use self-destructing links when sharing keys with teammates
Revoke keys immediately when team members leave
Enable API key usage monitoring and alerts

Don't

Hardcode API keys in source code
Commit keys to version control (even private repos)
Share keys via Slack, email, or chat platforms
Use production keys in development environments
Share keys with more people than necessary
Ignore key expiration warnings
Store keys in plain text files on servers

OWASP API Key Management FAQ

What are OWASP API key management best practices?

OWASP-aligned API key management means keeping keys out of source code, storing them in a secrets manager or platform secret store, rotating them regularly, monitoring usage, and revoking exposed keys immediately.

How should teams store API keys securely?

Production API keys should live in a secrets manager or encrypted platform secret store. Local development keys should stay in ignored `.env` files or a password manager, never in git, chat, email, or shared documents.

When should API keys be rotated?

Set a rotation policy based on provider guidance and your risk requirements. For planned rotation, update and verify consumers before revoking the old key. Revoke an exposed key promptly; do not wait for the next scheduled rotation.

How should teams monitor API key usage?

Enable provider logs and alerts for unusual traffic, unexpected locations, permission changes, or use by inactive services. Keep an inventory that maps each key to an owner, service, environment, and rotation date.

Secure Sharing When You Must

Sometimes you need to share an API key with a teammate, contractor, or collaborator. Avoid pasting the raw credential into chat or email. Use our secure API key handoff checklist to verify the recipient, choose a short expiry, and deliver the key. A one-time link controls message retrieval; it does not revoke the API key or prevent the recipient from keeping a copy.

Send a link instead of pasting the raw credential into a message
End-to-end encryption protects the key during transmission
Revoke the provider credential when the recipient no longer needs access

Treat the full link as a secret. See SnapPwd's encryption, reveal behavior, and limitations before use.

Need to Share a Secret Securely?

When you need to share an API key, password, or credential with someone, use SnapPwd to create a secure, self-destructing link. No signup required.

Share a Secret Securely