How to Set Up API Key Security for Developer Projects

Why API Key Security Matters

API keys are credentials that grant access to external services, databases, and internal APIs. A compromised key can lead to data breaches, unexpected billing charges, and service disruption. According to the OWASP Top 10, broken authentication is the second most critical web application security risk. Most authentication breaches involve hardcoded credentials in source code.

The average cost of an API-related data breach exceeds $5 million according to IBM's 2025 Cost of a Data Breach Report. Following basic key management practices prevents the majority of these incidents.

Step 1: Never Hardcode Keys in Source Code

The most common cause of leaked API keys is committing them to a git repository. Even if you delete the key from the code later, it remains in the git history. Scan your repositories with tools such as truffleHog or gitleaks before pushing code to public repositories.

Use environment variables to inject keys at runtime. In a Node.js project, use a .env file during local development:

OPENAI_API_KEY=sk-...

Load the variables with the dotenv package. Never commit .env files to version control. Add .env to your .gitignore file and use a .env.example file to document which variables your application needs without exposing actual values.

Step 2: Use a Secrets Manager for Production

For production deployments, environment variables are not enough. Use a dedicated secrets manager such as HashiCorp Vault, AWS Secrets Manager, or Google Cloud Secret Manager. These services encrypt secrets at rest, provide access controls, and log every access event.

AWS Secrets Manager rotates credentials automatically for supported services such as RDS. Rotation means that even if a key is compromised, it is only valid for a limited time. For cloud-based applications, inject secrets at runtime through the secrets manager's API rather than storing them in the deployment environment.

Step 3: Scope Keys to Minimum Required Permissions

Most API providers allow you to create multiple keys with different permission levels. Create a separate key for each service or environment with only the permissions that service needs. If a key for a read-only reporting service is compromised, the attacker cannot write data or modify configurations.

Review your API key permissions quarterly. Remove keys that are no longer in use. Most cloud providers show the last-used timestamp for each key. Delete any key that has not been used in more than 90 days.

Step 4: Rotate Keys Regularly

Key rotation limits the blast radius of a compromised key. Rotate production keys at least every 90 days. Some organisations rotate keys every 30 days for high-risk services.

Use zero-downtime rotation to avoid service interruption. Create a new key, deploy it alongside the old key, wait for all services to pick up the new key, and then revoke the old key. Automated rotation tools handle this process without manual intervention.

If you suspect a key has been compromised, revoke it immediately and generate a new one. Do not wait for the next scheduled rotation. Document the reason for revocation in your security incident log.

Step 5: Monitor and Audit Key Usage

Enable audit logging for all API key usage. Cloud providers log every API call, including the key ID, timestamp, source IP address, and action performed. Review these logs weekly for unusual patterns such as access from unexpected geographic locations or high volumes of requests outside normal business hours.

Set up alerts for anomalous usage. AWS CloudWatch, Datadog, and other monitoring platforms can trigger alerts when API call volume exceeds a baseline threshold. If you receive an alert at 2 am for activity that usually occurs during business hours, investigate immediately.

Additional Hardening

Use short-lived tokens where possible. Instead of distributing permanent API keys to services, use OAuth 2.0 with short-lived access tokens and refresh tokens. Short-lived tokens expire automatically, reducing the window of exposure if they are compromised.

Restrict API key usage to specific IP addresses or CIDR ranges where the service supports it. Combining IP restrictions with short-lived tokens provides layered protection against key misuse.