Edit: Never Hardcode JWT Secrets: What Goes W…

Posts›Never Hardcode JWT Secrets: What Goes W…

PublishedView Live →

Title

Slug

Preview: https://jwtsecretgenerator.com/blog/never-hardcode-jwt-secrets

⚠ Changing the slug will break existing links to this post.

Description / Excerpt

144 / 180 characters

Content (Markdown)

## Hardcoded JWT Secrets Still Show Up Everywhere

Every week, security researchers find hardcoded JWT secrets in public GitHub repositories. Some of those repositories have tens of thousands of stars. The developers who shipped them are not careless — they often did not understand the chain of consequences from a "temporary" string in `auth.js` to permanent compromise.

This guide explains how hardcoded secrets leak, why git history makes deletion insufficient, how to load secrets from the environment safely, and what to do if you already committed one. Generate replacements with the [JWT Secret Generator](/tools/jwt-secret-generator) before you rotate.

## How Hardcoded Secrets Get Exposed

The code starts innocuously:

```javascript
// auth.js
const jwt = require('jsonwebtoken');
const SECRET = 'mysupersecretkey'; // Fine for testing, right?

app.post('/login', (req, res) => {
  const token = jwt.sign({ userId: user.id }, SECRET);
  res.json({ token });
});
```

It gets pushed to GitHub. Maybe the repo is private. Three months later, someone opens it for a demo. Or the organisation flips visibility by mistake. Or GitHub secret scanning notifies you — after bots that index secrets have already scraped the commit.

Once a secret is in git history, treat it as compromised permanently. Deleting the line in a later commit does not erase earlier blobs. Forks and clones retain the old value. `git filter-branch` or BFG can rewrite history, but anyone who cloned before the rewrite still has the secret.

## The Git History Problem

```bash
# An attacker can find your old secret even after you delete the file
git log --all --full-history -- auth.js
git show <old-commit-hash>:auth.js
```

The fix is not "delete the file and push a new commit." The fix is: **rotate the secret immediately**, then clean history, then prevent recurrence with scanning and hooks.

## The Correct Approach: Environment Variables

```bash
# .env (local development only — in .gitignore)
JWT_SECRET=<generated-at-jwtsecretgenerator.com>

# .env.example (safe to commit — no real values)
JWT_SECRET=your-256-bit-secret-here
```

```javascript
// auth.js — correct approach
const jwt = require('jsonwebtoken');

const SECRET = process.env.JWT_SECRET;
if (!SECRET) {
  throw new Error('JWT_SECRET environment variable is required');
}

const token = jwt.sign({ userId: user.id }, SECRET, {
  algorithm: 'HS256',
  expiresIn: '15m',
});
```

The `if (!SECRET) throw` check matters — it makes missing secrets a **startup failure** rather than a runtime bug that signs tokens with `undefined` or an empty string.

Never commit `.env`. Commit `.env.example` with placeholders only. Document generation via `/tools/jwt-secret-generator` in your README so new developers do not invent weak strings.

## Platform-Specific Storage

**Vercel:**  
Dashboard → Project → Settings → Environment Variables → Add `JWT_SECRET`

**Railway:**  
Project → Variables → Add variable

**Heroku:**  
`heroku config:set JWT_SECRET=your-secret-here`

**AWS (Lambda or ECS):**  
Store in AWS Secrets Manager, fetch at startup:

```javascript
const { SecretsManagerClient, GetSecretValueCommand } = require('@aws-sdk/client-secrets-manager');

async function loadJwtSecret() {
  const client = new SecretsManagerClient({ region: 'us-east-1' });
  const { SecretString } = await client.send(
    new GetSecretValueCommand({ SecretId: 'prod/jwt-secret' }),
  );
  if (!SecretString) throw new Error('Empty secret');
  return SecretString;
}
```

**Kubernetes:**

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: jwt-secret
type: Opaque
stringData:
  JWT_SECRET: "your-secret-here"
```

Mount as an environment variable in the pod spec. Prefer external secret operators in larger clusters so values never sit in plain manifests in git.

For deeper storage patterns, see [where to store JWT secrets](/blog/where-to-store-jwt-secrets) and [how to store JWT secrets securely](/blog/how-to-store-jwt-secrets-securely).

## What to Do If You Already Committed a Secret

1. Generate a new secret immediately at the [JWT Secret Generator](/tools/jwt-secret-generator).
2. Deploy the new secret to production using a [grace-period rotation](/blog/how-to-rotate-jwt-secrets).
3. Treat old tokens signed with the leaked secret as untrusted; shorten TTLs and invalidate refresh sessions if needed.
4. Clean git history with BFG Repo Cleaner (`bfg --replace-text secrets.txt`) or equivalent.
5. Force-push only after coordinating with the team — and assume prior clones retain the leak.
6. Enable GitHub secret scanning on all repositories.
7. Add a pre-commit hook with `gitleaks` or `detect-secrets`.

## Pre-commit Hook Setup

```bash
# Install gitleaks
brew install gitleaks  # macOS
# or: go install github.com/gitleaks/gitleaks/v8@latest

# Add to .git/hooks/pre-commit
#!/bin/bash
gitleaks protect --staged -v
if [ $? -ne 0 ]; then
  echo "Secret detected. Commit blocked."
  exit 1
fi
```

CI should run the same scanner on every pull request. Hooks alone are not enough — they are skipped with `--no-verify`.

## Production Checklist

- [ ] No JWT secrets in source, Docker images, or ticket screenshots
- [ ] Startup fails closed when `JWT_SECRET` is missing
- [ ] Dev / staging / production secrets differ
- [ ] Secret scanning enabled on the host platform
- [ ] Rotation runbook tested
- [ ] Algorithm allowlists set on verify

## Frequently Asked Questions

### Is a private GitHub repository safe enough for hardcoded secrets?

No. Private repos still leak through misconfiguration, contractor access, laptop theft, and tooling that indexes clones. Secrets belong in environment configuration or a vault, not in blobs.

### Can I keep a hardcoded secret for local development only?

Prefer a local `.env` that is gitignored. If you must ship a demo, use an obviously fake placeholder and refuse to start when the placeholder is detected in non-dev environments.

### What is the difference between encoding a secret in Base64 and encrypting it?

Base64 is encoding, not protection. Anyone who reads the string recovers the bytes. Encryption and vault storage protect confidentiality; Base64 only changes representation. See [Base64 in JWTs](/blog/base64-encoding-jwt-explained).

### How often should I rotate after a hardcoded secret leak?

Immediately. Do not wait for a quarterly schedule. Use dual-secret acceptance until access tokens expire, then remove the leaked key permanently.

925 words · ~5 min readMarkdown guide →

Tags (4/8)

jwtsecuritysecrets-managementdevops

Author Name

Status

Cover Image URL (optional)

Danger Zone

Deleting this post sets its status to "deleted". It can be recovered via the API.