What are API key storage best practices?

The core best practices: (1) never store API keys in git repositories or source code, (2) don't store them in browser localStorage or sessionStorage, (3) avoid cloud docs like Notion or Google Docs, (4) use encrypted vaults like API Locker for your personal keys, (5) use .env files with .gitignore for per-project config, and (6) use secrets managers like AWS SSM or HashiCorp Vault for production applications.

Is it safe to store API keys in browser localStorage?

No. Browser localStorage is readable by any JavaScript on the same origin, which includes third-party scripts, ads, and browser extensions with broad permissions. Any XSS vulnerability in your application exposes everything in localStorage. API keys should never be stored in localStorage — use a server-side environment variable or a proper secrets manager instead.

What happens if an API key is committed to git?

You should assume it's compromised and revoke it immediately. Even if the repo is private, keys in git history are accessible to anyone who clones the repo, GitHub employees, and automated scanners that monitor for leaked credentials. GitHub's secret scanning will alert you and may automatically revoke some key formats. The safe path: revoke the key, generate a new one, and use git-filter-repo to scrub the old key from history.

Can I store API keys in environment variables on the server?

Yes — server-side environment variables are the correct approach for production applications. They're not stored in source code, not accessible from the browser, and can be managed separately from your codebase. Use your hosting platform's secrets UI (Vercel, Railway, Heroku, etc.) or a secrets manager for production values.

API Key Storage Best Practices

Storage Locations

Where to Store API Keys — and Where Not To

Not all storage is equal. The difference between "safe" and "unsafe" comes down to three factors: encryption at rest (is the key protected if the storage is accessed?), access control (who else can read this?), and exposure surface (how many ways can this leak?).

🚫 Never Store Keys Here

Git repositories

Even in private repos. Git history is permanent. GitHub's secret scanning indexes everything. If committed, treat the key as compromised — revoke it immediately.

Browser localStorage / sessionStorage

Readable by any JavaScript on the page — including third-party scripts and extensions. One XSS vulnerability exposes everything. This is how client-side apps get pwned.

Slack, Teams, or Discord messages

Chat platforms index and search everything. Workspace admins have access. Free Slack retains messages. Screenshots get shared. Chat is for communication, not secrets storage.

Notion, Google Docs, Confluence

Cloud docs store content on the provider's servers. Account compromise = key exposure. Many teams share workspaces accidentally. Encryption is at infrastructure level, not per-user.

Email is not encrypted end-to-end by default. It lives on mail servers indefinitely. "Email it to yourself" is one of the most common bad habits. Email metadata alone can be a security issue.

Plain text files (unencrypted)

Keys.txt, api_keys.md, passwords.txt on your desktop or in a folder. No encryption, syncs to cloud storage accidentally, visible in file search. If your machine is accessed, all keys are immediately readable.

Source code (hardcoded strings)

Even if you never commit it, hardcoded keys appear in logs, error messages, stack traces, and code-sharing tools. The key leaks before you even think about git.

✓ Safe Storage Locations

Encrypted vault (API Locker)

AES-256-GCM encryption behind a master password that never leaves your device. Purpose-built for API keys with site detection, labeling, and expiry tracking. The correct home for your personal key collection.

.env files + .gitignore

Per-project config loaded at runtime. Safe when .env is in .gitignore and not synced to cloud. Still plaintext on disk, but scoped to one project. Pair with API Locker as the master source.

Hosting platform secrets UI

Vercel, Railway, Render, Heroku, Fly.io — all have built-in environment variable management. Encrypted, not in source code, injected at build/runtime. The right approach for production deployments.

AWS Secrets Manager / SSM Parameter Store

For applications that need to fetch secrets at runtime. IAM access control, audit logging, automatic rotation. Right for production services, not for personal dev workflows.

Team secrets manager (Doppler, Infisical)

Encrypted storage with team access control, audit logs, and platform integrations. Right for teams sharing secrets across environments and CI/CD pipelines.

OS keychain (as a last resort)

macOS Keychain and Windows Credential Manager are encrypted by the OS. Better than plaintext files, but harder to organize and not developer-friendly. Use API Locker instead for a better UX.

Risk Reference

Storage Location Risk Levels

Storage Location	Encrypted	Risk Level	Primary Threat
Git repository (public)	No	Critical	Automated scanners, public access, permanent history
Browser localStorage	No	Critical	XSS attacks, malicious extensions, shared computers
Hardcoded in source	No	Critical	Accidental commits, logs, error messages, code sharing
Slack / Teams DMs	In transit only	High	Account compromise, workspace admin access, screenshots
Notion / Google Docs	Infrastructure only	High	Account compromise, shared workspaces, provider access
Plain text files	No	High	Machine access, cloud sync, file search exposure
Git repository (private)	No	Medium	Accidental public, collaborator access, provider breach
Password manager secure notes	Yes	Medium	Master password compromise, sync vulnerability
.env file (correct .gitignore)	No	Low-Medium	Machine access, accidental cloud sync
API Locker (AES-256)	Yes — AES-256-GCM	Low	Master password compromise (zero-knowledge, no cloud)
AWS SSM / HashiCorp Vault	Yes	Low	IAM misconfiguration, excessive permissions

By Context

The Right Storage for Each Scenario

💻

Personal key collection (your vault)

Use: API Locker. This is the master copy of every key you own. Encrypted, labeled by provider, with expiry dates. When you need a key for any reason, this is where you look first.

🗂️

Local development project

Use: .env files loaded by dotenv. Add .env to .gitignore on project creation. Keep a .env.example with placeholder values in git for documentation.

🚀

Production deployment

Use: hosting platform secrets. Set environment variables in your Vercel/Railway/Fly.io dashboard. Never deploy a .env file or commit production keys anywhere.

👥

Team shared secrets

Use: Doppler or Infisical. Centralized storage with access control. Revoke access when someone leaves. Sync to CI/CD pipelines and cloud platforms automatically.

🏭

Production application fetching secrets

Use: AWS Secrets Manager, SSM Parameter Store, or HashiCorp Vault. Application fetches secrets at runtime via SDK. No secrets in deployment artifacts or environment config files.

🔄

CI/CD pipeline

Use: GitHub Actions secrets, GitLab CI variables, or your secrets manager. Set at the repo/org level, never stored in workflow YAML files. Mask values in logs.

API Key Storage Best Practices:
Where To — and Where Never To

Where to Store API Keys — and Where Not To

Storage Location Risk Levels

The Right Storage for Each Scenario

Store Your Keys Where They Actually Belong

API Key Storage Best Practices:Where To — and Where Never To

Where to Store API Keys — and Where Not To

Storage Location Risk Levels

The Right Storage for Each Scenario

Related Guides

Store Your Keys Where They Actually Belong

API Key Storage Best Practices:
Where To — and Where Never To