Hardcoded JWT or session secret — how to fix it

The secret that signs your JWTs or sessions is the key to every user's identity. If it is hardcoded in source, or falls back to a default when the environment variable is missing, anyone who knows it can forge a valid token for any user, including an admin. Read it from the environment with no fallback, and fail loudly if it is not set.

Why it's a problem

Your server trusts a token because it can verify the signature with this secret. If an attacker has the secret, they can mint a token with any claims they want, a different user id, an admin flag, and your server will accept it as genuine. A fallback like process.env.JWT_SECRET || 'dev-secret' is the same as hardcoding, because the moment the variable is unset in production the default is used.

const token = jwt.sign(
  payload,
  process.env.JWT_SECRET || "dev-secret"
);

const secret = process.env.JWT_SECRET;
if (!secret) throw new Error("JWT_SECRET not set");
const token = jwt.sign(payload, secret);

Why AI tools write this

The fallback pattern is a common training-data idiom because it makes the code run in development without setup. It works locally, so it survives to production, where a missing environment variable silently activates the public default value.

The quick fix

• Read the signing secret from an environment variable with no fallback default.
• Throw or refuse to start if the secret is not set, rather than using a default.
• Use a long, random secret, and rotate it if it was ever hardcoded (this invalidates existing sessions).