Where to keep API keys and passwords: secrets 101

What a secret is

A secret is a "key others must not see": API keys, database passwords, third-party tokens, signing keys. Once one leaks, others can impersonate you, run up your bill, or steal your data. So the point isn't just "how to use it" — it's "how to keep it hidden."

Where they must never go

• Front-end JavaScript: anything that reaches the browser is visible to the user. A secret in the front end is a public secret.
• Committed to Git: even if you delete it later, it's still in the history — that's a leak. On a public repo, bots scan for it within seconds.

Where they belong

• Environment variables / your platform's secret store: put secrets in your deploy platform's secret store or env vars (e.g. Cloudflare) and read them from there — never hard-coded in the source.
• For local development, use a file like .env, but always add it to .gitignore and never commit it.

This is the industry norm of "separating config from code" (the 12-factor config principle): the same code runs in any environment by swapping the secrets.

Principles for using them

• Least privilege: give a key only the permissions it needs — don't use a max-privilege root key everywhere.
• Expiring and revocable: prefer keys you can time-limit and revoke at any time, so a leak can be stopped.
• Different secrets per environment: keep production and test separate, so a test leak doesn't touch production.

What to do after a leak

Rotate immediately (replace and revoke the old one) — that's the only reliable fix. Remember: if it ever reached the front end, Git history, a chat log, or a screenshot, treat it as leaked — don't gamble. Revoke the old key, generate a new one, and update the secret store.

Next steps

• Set secrets on the platform when deploying: Deploy to Cloudflare Pages
• A login system uses secrets heavily too: Build a login system with AI