JWT Secret Hardcoded in Source Code: Risk and Fix

JSON Web Tokens (JWTs) are the backbone of modern stateless authentication. They allow your server to verify user identity without querying a database on every request. However, the entire security of a JWT system relies on a single string: the signing secret.

If an attacker obtains your JWT secret, they can forge valid authentication tokens for any user in your system, including administrators, bypassing the login screen entirely.

The Problem: Hardcoded Secrets

During development, it is common to hardcode a string to get authentication working quickly:

javascript
// DANGEROUS CODE
const token = jwt.sign(
  { userId: user.id }, 
  'my_super_secret_dev_key', // Hardcoded secret
  { expiresIn: '1h' }
);

If this code makes it into a git commit, your application is compromised. Even if the repository is private, code can be leaked, employees leave, and backups can be exposed.

The Fix: Environment Variables

The signing secret must never exist in your source code. It must be injected at runtime via environment variables.

Step 1: Update Your Code

Modify your token generation and verification logic to read from process.env.

javascript
// SECURE CODE
if (!process.env.JWT_SECRET) {
  throw new Error("FATAL: JWT_SECRET environment variable is not set.");
}

const token = jwt.sign(
  { userId: user.id }, 
  process.env.JWT_SECRET, 
  { expiresIn: '1h' }
);

Step 2: Set the Variable

Generate a strong, cryptographically secure random string. Do not use words or easily guessable phrases.

bash
# Generate a secure 64-character hex string
openssl rand -hex 32

Add this string to your production environment variables in your hosting provider (e.g., Vercel, AWS, Render).

Step 3: Rotate the Compromised Key

If your key was hardcoded in production, you must rotate it immediately. Change the JWT_SECRET in your environment variables. *Note: Rotating the key will invalidate all existing user sessions, forcing everyone to log in again. This is disruptive, but strictly necessary.*

Want CodeAudit to check your repo for this automatically? Join the waitlist.

Frequently Asked Questions

Q: Can I use the same secret for development and production? A: Never. Your local development environment should use a dummy secret (e.g., dev_secret_only), while production must use a cryptographically secure, hidden key.

Q: How does CodeAudit help? A: CodeAudit automatically scans your entire codebase for hardcoded secrets, including JWT keys, API tokens, and database passwords, alerting you before they reach production.

Want CodeAudit to check your repo for this automatically? Join the waitlist.