How to Store API Keys and Secrets Safely in Development
Store API keys, tokens, passwords, and application secrets so they are less likely to be exposed in source code, Git repositories, CI/CD output, container images, or routine configuration files.
Keep secrets out of code; limit access; use the right secret store; prevent accidental exposure; rotate when necessary
This is an editorial framework, not an official standard. API keys, access tokens, database passwords, private application credentials, webhook secrets, client secrets, signing keys, and service-account credentials can be application secrets. Public API identifiers, non-sensitive configuration, public certificates, and values designed to be public are different.
Keep real secrets out of source code
Do not generally embed real credentials in source files, committed configuration, scripts, frontend bundles, container build files, or infrastructure templates. Once a secret is committed, removing the visible line later does not necessarily remove it from repository history or existing clones. Treat a real committed secret as a potential exposure and rotate or revoke it where possible rather than relying on deletion alone.
Frontend code is not a secret store
Code delivered to a browser, mobile device, or other client can generally be inspected even when minified, obfuscated, or populated through a frontend environment variable. Do not place server-side credentials there. Some APIs intentionally use public client identifiers, so distinguish those from privileged secrets.
Environment variables and .env files
Environment variables can separate secrets from code, but are a delivery and configuration mechanism, not a complete secrets-management system. They may be exposed through access to a process or deployment, child-process inheritance, logging, debugging, or configuration mistakes. Local .env files can be useful when excluded from shared source control; use placeholders in .env.example files.
Use an appropriate secret store for each environment
A dedicated secret-management system may provide centralized storage, access control, auditing, rotation support, workload-identity integration, and reduced distribution of plaintext files, depending on the product and configuration. Use a CI/CD platform's supported secret mechanism for automation and restrict who can read or change it. Separate development, test or staging, and production credentials where practical so a local or lower-environment exposure has less impact.
| Situation | Better first approach | Important limit |
|---|---|---|
| Local development | Ignored local secret/config mechanism or developer secret store | Prevent accidental source-control commits |
| CI/CD | Platform-supported secret storage | Avoid logs and overly broad access |
| Production workload | Managed secret store or workload identity where supported | Configuration and permissions still matter |
| Human transfer | Provider-native delegation or temporary secret delivery | Verify recipient and authorization |
| Frontend app | Keep server-side secrets off the client | Client-delivered code cannot conceal confidential credentials |
Limit access and prevent accidental exposure
Scope a credential to the resources and actions a workload actually needs, such as read-only access, limited service scope, or environment-specific access. Where supported, workload identity, service identity, role-based temporary credentials, or short-lived tokens can reduce reliance on long-lived static secrets. Do not intentionally log secrets in application logs, CI/CD output, debug traces, error messages, HTTP request logs, or shell output. Masking or redaction can be helpful defense in depth, but may not detect every secret.
Containers, rotation, and response to a Git commit
Avoid baking long-lived secrets into container image layers or build artifacts; removing a value in a later layer may not remove it from earlier history. Prefer runtime injection or workload identity where appropriate. Rotate based on risk, including confirmed or suspected exposure, an accidental commit, unauthorized sharing, personnel changes, provider requirements, or organizational policy. Secret-scanning tools can detect patterns in repositories, commits, and CI/CD workflows, but detection is imperfect.
If a real secret reaches Git or another exposed channel, follow our step-by-step response guide on what to do if an API key or secret is exposed: revoke or rotate it where possible, update the application, remove the value from current code, and assess repository visibility, logs, artifacts, and related credentials. History cleanup does not replace rotation.
Related workflows
For an authorized human-to-human transfer, see how to share API keys securely. For SSH-specific access, see SSH keys and server access. When a person leaves or changes roles, use the account-access handoff guide; do not routinely share private SSH keys.
Where Paste & Purge fits
Paste & Purge can help transmit a temporary text secret to a verified, authorized recipient when a provider-native secret-management or access mechanism is not preferable. It is not a secret manager, CI/CD secret store, runtime configuration service, key-management service, credential-rotation service, IAM platform, or source-code scanner. Do not use it to manually shuttle production secrets when workload identity, a managed secret store, or a provider-native mechanism is better.
Review your application secrets
- Are any real secrets hardcoded?
- Are secret .env files excluded from source control?
- Are frontend bundles free of server-side credentials?
- Are CI/CD secrets protected from logs?
- Are production credentials separated from development?
- Are permissions scoped appropriately?
- Can workload identity replace a static credential?
- Are container and build artifacts free of baked-in secrets?
- Are exposed credentials rotated?
- Do former team members still have access?
- Are secret owners documented?