How to Keep API Keys and Passwords Out of Your Code

When you are building something quickly, it is tempting to paste an API key or database password straight into your code. It works immediately. It is also one of the most common ways small projects get compromised, sometimes within minutes of the code becoming public.

Keeping secrets out of your code is a habit you can learn on day one. Here is how.

What counts as a secret

• API keys and access tokens.
• Database usernames and passwords.
• Private keys, such as those used for signing or encryption.
• Webhook signing secrets.
• OAuth client secrets.
• Passwords for email, storage or any service your code uses.

If someone could use it to access a system, spend money or impersonate your application, treat it as a secret.

How secrets leak

• Committed to a repository. Once a secret is in Git history, it stays in every copy of the repository even if you delete it in a later commit.
• Public repositories. Automated tools constantly scan public code for keys. Leaked cloud and payment keys can be abused very quickly.
• Front-end code. Anything in JavaScript that runs in a visitor's browser can be read by anyone. There is no hiding a secret there.
• Logs and error messages that print configuration values.
• Screenshots, screen shares and support tickets.
• Chat messages and AI prompts. Pasting a key to ask for help sends it to another service.

Use environment variables and a local .env file

The standard approach is to keep configuration outside your code and load it when the program runs.

1. Store secrets in environment variables on the server or hosting platform.
2. For local development, use a .env file that holds values like the name of a key and its value, one per line.
3. Add .env to your .gitignore file so Git never tracks it. Do this before you create the file, not after. Our Git for beginners guide explains what .gitignore does.
4. Commit a .env.example file with the same setting names but placeholder values, so others know what to configure.
5. Read the values in your code through your language or framework's configuration tools, never by writing the secret itself.

Respect the browser boundary

Some services issue two kinds of keys: a publishable key designed to be visible in browsers, and a secret key that must stay on the server. Use only the publishable kind in front-end code. If a feature needs a secret, send the request to your own server first, and let the server call the other service with the secret.

Use your platform's secret storage

Hosting platforms, deployment pipelines and cloud providers offer protected places for secrets, often with masking so values do not appear in logs. For teams, a dedicated secret manager or a shared vault in a password manager is better than passing keys around in messages.

Limit the damage any one key can do

• Use separate keys for development, testing and production.
• Choose restricted keys with only the permissions your code needs, when the service offers them.
• Set spending or usage limits where possible.
• Rotate keys periodically and whenever someone with access leaves the project.

Catch mistakes before they ship

Many code hosting platforms offer secret scanning that warns you, or blocks a push, when something looks like a key. Pre-commit tools can scan your changes on your own computer before they are committed. Turn these on; they are inexpensive insurance.

If you use an AI coding assistant, keep secrets out of prompts and review its changes for hard-coded values. Our guide to using an AI coding assistant wisely covers this.

If a secret leaks

Act in this order:

1. Revoke or rotate the secret immediately in the service that issued it. This is the step that actually stops misuse. Removing it from code does not.
2. Check the service's logs and billing for activity you do not recognize.
3. Replace the secret in your environment settings and redeploy.
4. Remove it from your code and, if appropriate, from Git history, while still treating the old value as compromised.
5. Tell the right people, including your team and, if customer data could be affected, someone who can assess notification obligations.

Secrets are part of nearly every integration. Our explainers on what an API is and what a webhook is show where they appear.

Frequently asked questions

Is it safe to keep secrets in a private repository?

It is safer than a public one, but still risky. Private repositories get cloned to laptops, shared with contractors and occasionally made public by mistake. Keep secrets out of all repositories.

I deleted the key from my code. Am I safe?

No. The key still exists in Git history and in any copies of the repository. Revoke or rotate it in the issuing service right away.

Can I hide an API key in my JavaScript?

No. Anything delivered to a browser can be viewed by visitors. Use publishable keys meant for browsers, and keep secret keys on your server.