Securing API Keys

An API key is a secret string that identifies and authorizes a client calling an API.

Whoever holds the key can act as that client, so keys must stay secret.

Treat an API key with the same care as a password.

A leaked key lets an attacker make requests, run up costs, and access data, all while appearing to be a trusted client.

A common mistake is putting a key directly in code:

This ends up in your repository and history, where anyone with access can read it.

Keep keys outside your code in environment variables.

The secret lives in the environment, not in your source files.

Add secret files to .gitignore so they are never committed:

If a key was ever committed, removing it later is not enough; it must be rotated.

Never embed a secret key in front-end or mobile code.

Anyone can inspect the app and extract it. Keep secret keys on the server and call the third-party API from there.

For production, store keys in a dedicated secrets manager.

Tools like Vault or a cloud secrets service encrypt keys, control access, and log who reads them.

Give each key only the permissions it needs.

A read-only key cannot delete data even if leaked. Scoping limits the damage of any single compromised key.

Rotation means replacing keys on a schedule and immediately after any suspected leak.

Short-lived keys reduce how long a stolen key remains useful to an attacker.

Lock keys down further by allowing only certain IPs or domains.

Then monitor usage. Unexpected traffic or new locations can reveal a key has been stolen.

If a key leaks, act fast:

• Revoke the old key immediately
• Issue a new one
• Review logs for misuse

Speed limits the harm a leaked secret can cause.

Where should a secret API key be stored in a production web app?

Protect API keys like passwords: keep them out of code and Git, store them in environment variables or a secrets manager, scope them to least privilege, rotate them, restrict and monitor usage, and revoke any leaked key fast.