Store JWT Secrets — Security Checklist
Most JWT incidents start with a leaked signing secret. Use this practical checklist to keep secrets out of git, separate environments cleanly, prefer a secrets manager in production, and plan kid-based rotation before you ever need an emergency incident response.
Last updated August 26, 2026
Steps
- 1
Never hardcode secrets in source code or commit them to git repositories.
- 2
Use .env files for local development only — add .env to .gitignore and never copy production values into tickets.
- 3
Set production secrets via your hosting platform or a secrets manager (AWS Secrets Manager, Vault, Doppler, GCP Secret Manager).
- 4
Generate separate secrets for development, staging, and production with the JWT Secret Generator.
- 5
Plan key rotation using the kid header before you need emergency rotation.
- 6
Audit logs and error handlers to ensure secrets and full tokens are never printed.
Frequently Asked Questions
Are environment variables secure enough?
For small production deployments they are a solid baseline. Growing teams should move to a dedicated secrets manager with access control, audit logs, and rotation APIs.
What if I committed a secret to git?
Rotate immediately and assume compromise — history retains deleted files. Scrub history only after the new secret is live everywhere.
Should mobile apps embed the JWT secret?
Never. HS256 secrets and RSA private keys belong only on trusted servers. Mobile and SPAs should use public clients with proper OAuth/OIDC flows.
How often should I rotate?
Rotate on a schedule (for example quarterly) and immediately after any suspected leak. Use dual-key verification so rotation does not force a hard outage.
Continue
Related tools and reading on JWTSecrets.