DEV Community: SHAHJAHAN MD. SWAJAN

JWT Security Checklist: 12 Things to Verify Before You Ship

SHAHJAHAN MD. SWAJAN — Mon, 27 Jul 2026 20:55:00 +0000

JWT authentication has more failure modes than most developers realise. Correct signature verification is necessary but far from sufficient. This checklist is what I run through before every production JWT deployment.

1. Secret Is Generated With a CSPRNG

Not a password. Not a UUID. Not a timestamp. A cryptographically secure pseudorandom number generator output.

In Node.js: crypto.randomBytes(32).toString('hex')

In Python: secrets.token_hex(32)

In the browser: jwtsecretgenerator.com/tools/jwt-secret-generator

A 256-bit CSPRNG secret takes 10^59 years to brute force at current GPU speeds.

2. Algorithm Is Explicitly Specified in verify()

// Wrong
jwt.verify(token, secret);

// Right
jwt.verify(token, secret, { algorithms: ['HS256'] });

3. exp Claim Is Present and Validated

Short-lived tokens (15 minutes) limit the damage from leaks. Verify your library is actually checking exp — some require explicit configuration.

4. iss and aud Claims Are Validated

Validates the token was issued by your service and intended for your API. Prevents token reuse across services.

5. Tokens Are in httpOnly Cookies, Not localStorage

localStorage is readable by any script on the page. httpOnly cookies are invisible to JavaScript.

6. HTTPS Is Enforced

JWT in a query parameter over HTTP is visible in every proxy, CDN, and server log on the path. Use the Authorization: Bearer header over HTTPS only.

7. Refresh Tokens Are Server-Side Revocable

Short access tokens + server-side refresh tokens = the ability to end sessions immediately. Long-lived access tokens without refresh logic cannot be revoked.

8. The jti Claim Is Used If You Need Immediate Revocation

Store revoked jti values in Redis with TTL matching token expiry. Check on every request. Adds one Redis lookup per request — worth it for high-security endpoints.

9. Different Secrets for Each Environment

Dev secret leaks should not compromise production. Keep them separate.

10. Secret Is Not in Source Code or Version Control

Check: git log -S "JWT_SECRET" -- . — if any results appear, rotate immediately.

11. Error Messages Do Not Reveal Why Verification Failed

// Bad — tells attacker whether to try a different token or different secret
return res.status(401).json({ error: 'Token expired' });

// Good
return res.status(401).json({ error: 'Unauthorized' });

12. Payload Does Not Contain Sensitive Data

JWT payload is base64, not encrypted. Decode any JWT in 3 seconds at jwt.io. Never put passwords, full PII, or financial data in a JWT payload.

The full version of this checklist with code examples for each point is at jwtsecretgenerator.com/blog/jwt-security-checklist-2026.

What Size JWT Secret Do I Need? Key Length Explained

SHAHJAHAN MD. SWAJAN — Sat, 25 Jul 2026 21:02:00 +0000

"How long should my JWT secret be?" is one of the most searched JWT security questions. The answer depends on your signing algorithm — but for the vast majority of applications, the answer is simple: 256 bits.

The Short Answer

Algorithm	Minimum Secret Size	Hex Characters	Bytes
-----------	--------------------:	---------------:	------:
HS256	256 bits	64	32
HS384	384 bits	96	48
HS512	512 bits	128	64

If you are using HS256 (the most common choice), generate a 256-bit (32-byte) random secret. That is 64 hexadecimal characters.

Why 256 Bits Is Enough

A properly random 256-bit key has 2^256 possible values. Even at a trillion guesses per second, brute-forcing a 256-bit secret would take longer than the age of the universe. NIST recommends a minimum of 128 bits for symmetric keys; 256 bits provides a comfortable security margin.

The real risk is not key length — it is using predictable secrets, reusing secrets across environments, or storing them insecurely.

When to Use 512 Bits

Use a 512-bit secret when:

You are signing with HS512 (the HMAC block size aligns with 512-bit keys)
Compliance requirements mandate longer key material
You want defense-in-depth in high-security or regulated environments

For standard HS256 production use, 512-bit secrets offer no practical security benefit over 256-bit — they just take more storage space.

How to Generate the Right Size

Use the JWT Secret Generator and select the preset that matches your algorithm:

128-bit — testing only, never production
256-bit — standard production (HS256)
512-bit — HS512 or high-security environments

// Node.js: 256-bit secret for HS256

const secret = require('crypto').randomBytes(32).toString('hex');

What NOT to Use

Passphrases or dictionary words ("my-super-secret-key")
UUIDs or short random strings (< 128 bits)
Base64-encoded short passwords
The same secret you use for other purposes (database encryption, API keys)

Bits, Bytes, and Characters Explained

Developers often confuse these units. Here is how they map for hex-encoded secrets:

256 bits = 32 bytes = 64 hexadecimal characters
512 bits = 64 bytes = 128 hexadecimal characters

When you see a 64-character hex string from the JWT Secret Generator, you have 256 bits of entropy. A 32-character string is only 128 bits — half the recommended minimum for HS256 production use.

Compliance and Industry Guidance

Standard / Source	Minimum Symmetric Key Size
NIST SP 800-131A	128 bits (112 effective)
OWASP JWT Cheat Sheet	256 bits for HS256
RFC 7518 (JWA)	Key size >= hash output size

Regulated industries (HIPAA, PCI-DSS, SOC2) often require documented key management procedures. Using 256-bit random secrets satisfies the cryptographic requirement — but auditors also expect rotation policies, access controls, and secrets manager usage. Read how to store JWT secrets securely for storage patterns that satisfy compliance reviews.

Testing Your Key Size in Practice

After generating a secret, sign a test token and verify it:

Paste the token into the JWT Validator to confirm the signature and inspect the decoded payload. If verification fails, check that your secret has no trailing whitespace or newline characters from copy-paste.

Real-World Scenarios

Startup MVP: 256-bit HS256 secret in platform environment variables. Rotate manually when team members leave.

Growing SaaS: Move to AWS Secrets Manager or Doppler. Automate rotation with the kid header. Keep 256-bit keys — upgrading to 512-bit adds no practical benefit for HS256.

High-security API: HS512 with 512-bit secrets, short token TTL (15 minutes), refresh token rotation, and audience validation on every request.

Verify Your Setup

After generating a secret, sign a test token and verify it with the JWT Validator. Read the full key length comparison for deeper technical detail.

Related Guides

How to generate a JWT secret — step-by-step walkthrough
What is a JWT secret key — fundamentals
JWT best practices checklist — production security

Summary

For HS256 — the default choice for most APIs — use a 256-bit (64-character hex) randomly generated secret. This applies to virtually every web application, mobile backend, and internal service. Upgrade to 512-bit only for HS512 or explicit compliance requirements. The JWT Secret Generator defaults to the correct size for your selected algorithm. When in doubt, choose 256 bits in production. Shorter secrets are the most common cause of offline JWT cracking attacks.

I Audited 12 Open Source JWT Implementations and Found the Same 6 Mistakes

SHAHJAHAN MD. SWAJAN — Fri, 24 Jul 2026 20:47:11 +0000

I spent last month reviewing JWT implementations across 12 open-source Node.js projects on GitHub — ranging from starter templates with 2k stars to production boilerplates used by teams at real companies. I found the same 6 mistakes in almost every one.

None of these projects are bad. The developers are skilled. The mistakes are subtle, copy-paste errors from tutorials that nobody questioned.

Here they are.

Mistake 1 — The Secret Is Literally `"secret"`

I found this in three separate projects:

const token = jwt.sign({ userId: user.id }, "secret", { expiresIn: "1h" });

This secret is in every JWT tutorial on the internet. It is in the jwt.io documentation. It is in the jsonwebtoken README. Developers copy it and forget to replace it.

A 6-character ASCII secret has approximately 42 bits of entropy. A GPU cluster cracks it from a dictionary in milliseconds. Generate a real secret here — it takes 3 seconds and produces a 256-bit cryptographically random key.

Mistake 2 — `jwt.decode()` Used in Auth Middleware

// DANGEROUS — this is in a production auth middleware
const decoded = jwt.decode(req.headers.authorization.split(" ")[1]);
if (!decoded.userId) return res.status(401).send("Unauthorized");

jwt.decode() does not verify the signature. It reads the payload regardless of whether the token is valid, expired, or forged. An attacker can craft any payload they want and it will pass this check.

The fix is two characters: jwt.verify().

const decoded = jwt.verify(token, process.env.JWT_SECRET, { algorithms: ["HS256"] });

Mistake 3 — Algorithm Not Specified in `verify()`

// Missing algorithms option
jwt.verify(token, secret);

Without { algorithms: ['HS256'] }, the library trusts whatever algorithm is in the token's header. An attacker can create a token with alg: none and an empty signature — and jwt.verify() will accept it.

Always specify the expected algorithm explicitly.

Mistake 4 — Secret Committed to Version Control

// Found in config.js, committed to a public repo
module.exports = {
  jwtSecret: "productionsecretdonotshare2024",
  database: process.env.DATABASE_URL
};

Note the comment — "do not share." The developer knew this was sensitive. But it still ended up committed to a public repository.

Once in git history, a secret is compromised permanently. Even deleting the file does not remove it from history. Rotate immediately if this has happened to you.

Mistake 5 — Tokens Stored in localStorage

// Frontend code in multiple projects
localStorage.setItem("token", response.data.token);

// Later:
const token = localStorage.getItem("token");

localStorage is accessible to any JavaScript running on the page. A single XSS vulnerability — an improperly sanitised comment, a compromised npm package, a third-party script — and all stored tokens are exfiltrated.

Use httpOnly cookies for authentication tokens. They are invisible to JavaScript, making XSS token theft impossible.

Mistake 6 — Tokens Never Expire

// No expiresIn — token is valid forever
const token = jwt.sign({ userId: user.id }, secret);

A JWT without an exp claim never expires. If it is ever leaked — in a log file, an error response, a frontend cache — it remains valid indefinitely.

Always set expiresIn. For access tokens: 15 minutes. For long-lived sessions: use a refresh token pattern, not a long-lived access token.

The Pre-Ship Checklist

Before your next JWT implementation goes to production:

[ ] Secret generated with a CSPRNG, minimum 256 bits
[ ] Secret in environment variable, not in code
[ ] jwt.verify() used everywhere, never jwt.decode() alone
[ ] { algorithms: ['HS256'] } explicitly specified
[ ] expiresIn set on all tokens
[ ] Tokens in httpOnly cookies, not localStorage I have been using jwtsecretgenerator.com for generating secrets — it runs entirely in the browser using the Web Crypto API, nothing is sent to a server, and it produces the right bit length for your algorithm.

I Audited 12 Open Source Projects' JWT Implementations and Found the Same 6 Mistakes in All of Them

SHAHJAHAN MD. SWAJAN — Wed, 22 Apr 2026 19:37:47 +0000

It started with a throwaway comment in a code review.

I was scanning through a popular Node.js starter template on GitHub — one with over 4,000 stars, regularly featured in "best Express boilerplate" roundup articles. The kind of repo junior developers clone on day one and senior developers use as a starting point for new services. And buried inside config/default.js, I found this:

module.exports = {
  jwtSecret: "secret",
  jwtExpiry: "7d",
};

Not a placeholder. Not a comment warning you to change it. Just... "secret". Shipped to production in thousands of forks.

I closed the tab, then reopened it. Then I opened eleven more repos.

What I found over the next few hours was not reassuring. The same class of mistakes appeared again and again — not just in beginner repos, but in widely-used templates, production starter kits, and even a few packages with active contributors who clearly knew what they were doing. JWT is one of those technologies where the happy path works fine and the failure modes are invisible until someone is already inside your system.

Here are the six mistakes I found, what they look like in real code, why they matter, and how to fix them.

The 12 Repos: A Quick Note on Scope

To keep this constructive rather than a public callout, I'm not naming repositories directly. Instead I'll describe them by category. The sample included:

3 Express + MongoDB boilerplates (2,000–8,000 stars each)
2 NestJS starter kits
2 full-stack Next.js templates with built-in auth
1 Fastify REST API scaffold
1 Node.js microservices example repo from a major cloud provider's tutorial series
1 React Native + Node backend starter
1 GraphQL + Apollo Server template
1 open-source SaaS boilerplate with a paid tier All were JavaScript or TypeScript. All used jsonwebtoken or a thin wrapper around it. All had at least one of the six mistakes below. Eight had three or more.

Mistake 1 — The Hardcoded Static Secret

Frequency: 10 of 12 repos

// The most common pattern I found
const jwt = require("jsonwebtoken");

const SECRET = "mysecret123";

function generateToken(userId) {
  return jwt.sign({ userId }, SECRET, { expiresIn: "1d" });
}

function verifyToken(token) {
  return jwt.verify(token, SECRET);
}

Variations I encountered: "secret", "jwt_secret", "your-secret-key", "supersecret", "changeme", and my personal favourite, "TODO_REPLACE_THIS" — which had not been replaced in any of the commits going back two years.

Why it's dangerous:

The security of HMAC-based JWT (HS256, HS384, HS512) depends entirely on the unpredictability of the secret. If an attacker knows or guesses the secret, they can forge any token — including { "role": "admin" } tokens for users that don't exist.

A string like "mysecret123" has roughly 65 bits of entropy in theory, but in practice it's a dictionary target. Security researchers maintain public lists of common JWT secrets scraped from GitHub, Stack Overflow, and tutorial sites. If your secret appears in that list — and "secret", "mysecret", and "jwt_secret" absolutely do — a brute-force attack with a modern GPU takes seconds, not years.

For HS256, you need a minimum of 256 bits (32 bytes) of cryptographically random data. Not a memorable string. Not a UUID. Not your app name.

The fix:

// Generate once using Node's crypto module
const crypto = require("crypto");
console.log(crypto.randomBytes(32).toString("hex"));
// outputs: 3f2a1b9c4d8e7f6a... (64 hex chars = 256 bits)

Store this in an environment variable. Never in source code.

// In production
const SECRET = process.env.JWT_SECRET;
if (!SECRET || SECRET.length < 32) {
  throw new Error("JWT_SECRET must be set and at least 32 characters");
}

If you need a production-grade 256-bit secret right now, jwtsecretgenerator.com/tools/jwt-secret-generator generates one client-side using the Web Crypto API — nothing leaves your browser. It's the fastest way to get a properly random secret with zero server-side risk.

Mistake 2 — The `algorithm: "none"` Attack Surface

Frequency: 7 of 12 repos

The classic JWT algorithm confusion attack. Here's the vulnerable pattern I found repeatedly:

// Vulnerable — no algorithm allowlist
function verifyToken(token) {
  try {
    return jwt.verify(token, SECRET);
  } catch (err) {
    return null;
  }
}

An attacker who can intercept or modify a token can change the header from:

{ "alg": "HS256", "typ": "JWT" }

to:

{ "alg": "none", "typ": "JWT" }

Then strip the signature entirely. Older versions of some JWT libraries — and jsonwebtoken without explicit algorithm enforcement — will verify this token as valid, because a "none" algorithm means "no signature required." The attacker has just granted themselves any claims they want.

Here's what a decoded alg: none attack payload looks like in practice:

# Header (base64url decoded)
{"alg":"none","typ":"JWT"}

# Payload (base64url decoded)  
{"userId":"1","role":"admin","iat":1714000000}

# Signature
(empty string)

# Final token
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VySWQiOiIxIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzE0MDAwMDAwfQ.

The fix:

Always pass an explicit algorithms allowlist to jwt.verify(). This is not optional.

// Safe — explicit algorithm allowlist
function verifyToken(token) {
  try {
    return jwt.verify(token, SECRET, {
      algorithms: ["HS256"], // NEVER include "none"
    });
  } catch (err) {
    return null;
  }
}

If you use RS256 (asymmetric), explicitly allow only ["RS256"]. Never use an empty array or omit the option entirely.

Mistake 3 — Secrets Committed to Git

Frequency: 6 of 12 repos

A few repos had cleaned up their secrets into environment variables — but their Git history told a different story. You can search for this pattern yourself:

# GitHub code search query (do not run on live repos you don't own)
language:JavaScript "jwt.sign" "secret" NOT ".env"

Results: tens of thousands of public files. Many are tutorials. Many are not.

Here's the dangerous reality of Git history: even after you delete a secret from your codebase, it still exists in every commit before the deletion. Anyone who cloned the repo before you pushed the fix still has it. Anyone with access to GitHub's search can find it.

I found this specific pattern in a repo with 3,000+ stars — a .env.example file that had been copy-pasted directly into .env and committed:

# .env (committed by mistake, later deleted — but still in git log)
DATABASE_URL=mongodb://localhost/myapp
JWT_SECRET=f7k2j9x1_my_production_secret_do_not_share
STRIPE_SECRET_KEY=sk_live_...

The sk_live_ key had already been rotated. The JWT secret had not.

The fix:

Add .env to .gitignore before your first commit. Always.

# .gitignore
.env
.env.local
.env.production
*.pem

If a secret is already in your history, rotation is mandatory — not optional.

# Rotate immediately, then use git filter-repo to purge history
pip install git-filter-repo
git filter-repo --path .env --invert-paths

# Force push to all remotes (coordinate with your team first)
git push origin --force --all

Then rotate the secret itself, invalidating all existing tokens.

Mistake 4 — Expiration (`exp`) Not Enforced

Frequency: 5 of 12 repos

Signature verification and expiry validation are separate concerns. Some repos verify one and skip the other.

// Subtly broken — verifies signature but issues tokens that never expire
function generateToken(userId) {
  // No expiresIn option!
  return jwt.sign({ userId }, SECRET);
}

// And on the verification side, a custom decoder that only checks signature:
function getUserFromToken(token) {
  const decoded = jwt.decode(token); // decode, not verify
  if (decoded && decoded.userId) {
    return decoded.userId;
  }
  return null;
}

jwt.decode() does not verify the signature. It does not check expiry. It literally just base64-decodes the payload. If your auth middleware calls jwt.decode() instead of jwt.verify(), your entire auth layer is bypassed.

Even when jwt.verify() is used correctly, I found several repos that issued tokens with no exp claim at all. A token without exp never expires. Ever. If it leaks — in a log file, in a frontend error boundary, in a network request captured at a coffee shop — it's valid forever.

The fix:

// Always set expiresIn
function generateToken(userId) {
  return jwt.sign(
    { userId },
    SECRET,
    {
      expiresIn: "15m",      // short-lived access tokens
      algorithm: "HS256",
    }
  );
}

// Always use verify(), never decode() for auth
function verifyToken(token) {
  return jwt.verify(token, SECRET, {
    algorithms: ["HS256"],
    // clockTolerance: 30  (optional: allow 30s clock skew)
  });
}

For most applications: access tokens at 15 minutes, refresh tokens at 7 days stored in an httpOnly cookie.

Mistake 5 — Signing and Verification With Different Secrets

Frequency: 3 of 12 repos

This one is subtle and disproportionately common in microservice architectures. It surfaces as a maddening "invalid signature" error in production that works perfectly in development.

Here's the pattern from a multi-service repo:

// auth-service/src/token.js
const token = jwt.sign({ userId }, process.env.JWT_SECRET, {
  expiresIn: "1d",
});

// api-gateway/src/middleware/auth.js
const decoded = jwt.verify(token, process.env.APP_SECRET); // different env var name!

In docker-compose.yml for local development:

auth-service:
  environment:
    JWT_SECRET: "dev-secret"

api-gateway:
  environment:
    APP_SECRET: "dev-secret" # same value locally, easy to miss

In production the values diverged. Someone set APP_SECRET to a new rotated value and didn't update JWT_SECRET. Tokens signed by auth-service became immediately invalid everywhere else.

The fix:

Standardize the environment variable name across all services. Use a shared secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler) so all services draw from a single source of truth.

// Centralized config with validation — same module or same env var name across services
const config = {
  jwtSecret: process.env.JWT_SECRET,
  jwtAlgorithm: "HS256",
};

// Validate at startup, not at runtime
if (!config.jwtSecret) {
  throw new Error("JWT_SECRET is required");
}

module.exports = config;

And document which service signs, which services verify, and what the shared secret name is. Put it in your runbook.

Mistake 6 — Short Human-Readable Secrets With HS256

Frequency: 9 of 12 repos

This is the most insidious mistake because the code looks "fixed." The developer has moved the secret to an environment variable. They're not hardcoding it. They're being responsible. But the secret itself is:

JWT_SECRET=MyApp2024Secure!

Twelve characters. Entirely alphabetic with one symbol and a number. Memorable enough to type by hand.

Here's the entropy problem: HS256 operates on raw bytes. The question is not how long the string looks — it's how many possible values it could be.

Character set for typical "memorable" passwords:
- Lowercase letters: 26
- Uppercase letters: 26  
- Digits: 10
- Common symbols: 32
Total: ~94 characters

Entropy per character: log2(94) ≈ 6.5 bits
A 12-character password: 12 × 6.5 = ~78 bits of entropy

HS256 security requirement: 256 bits minimum
Shortfall: 178 bits

78 bits sounds like a lot until you realize that modern GPU clusters can crack bcrypt hashes at millions of attempts per second. JWT secrets are not bcrypt — they're HMAC-SHA256, which is orders of magnitude faster to brute force. Security researchers maintain curated dictionaries of common JWT secrets — "MyApp2024", company names, and any string that appears in public repos are all in there.

If your secret is human-generated, it's a target. Full stop.

The fix:

Use a CSPRNG (Cryptographically Secure Pseudorandom Number Generator) to generate 256+ bits of entropy. The result will not be memorable. That's the point.

// Node.js — run this once, save the output in your secrets manager
const crypto = require("crypto");

// 32 bytes = 256 bits
const secret = crypto.randomBytes(32).toString("base64url");
console.log(secret);
// Example output: 3Hs8dKj2mNpQrT5wXvYzAb7eGcFhIiJl (never use this specific value)

# Or from the shell
node -e "console.log(require('crypto').randomBytes(32).toString('base64url'))"

# Or with openssl
openssl rand -base64 32

The result looks like noise. It should. Store it in your secrets manager, inject it at runtime, rotate it when team members leave or secrets are suspected of compromise.

The Pre-Ship JWT Checklist

Before you deploy JWT-based auth, run through every item:

Secret quality

[ ] Secret is generated by a CSPRNG (not typed by a human)
[ ] Secret is at least 32 bytes (256 bits) for HS256
[ ] Secret is stored in a secrets manager or environment variable — never in code Code hygiene
[ ] .env is in .gitignore and was never committed
[ ] git log does not contain the secret in any historical commit
[ ] jwt.verify() is used everywhere (never jwt.decode() for auth) Algorithm enforcement
[ ] algorithms option is explicitly set in jwt.verify()
[ ] "none" is not in the allowed algorithms list
[ ] If using RS256/ES256, private key never leaves the signing service Token lifecycle
[ ] All tokens have an exp claim (expiresIn option is set)
[ ] Access token expiry is 15–60 minutes maximum
[ ] Refresh tokens are stored in httpOnly cookies, not localStorage Multi-service safety
[ ] All services use the same environment variable name for the JWT secret
[ ] Secret is sourced from a shared secrets store, not per-service .env files
[ ] Startup validation throws if JWT_SECRET is missing or too short

Closing Thought

None of these mistakes are exotic. They're copy-paste errors, tutorial leftovers, and configuration drift between environments. The reason they appear in repos with thousands of stars is the same reason they appear everywhere: JWT's happy path is completely invisible to security issues. The token works. Auth passes. Tests pass. Nothing breaks until someone exploits it.

The most important item on the checklist is the first one. A CSPRNG-generated secret neutralizes most of the other risks at source — you can't brute force 256 bits of true randomness, even with excellent tooling. Get that right, enforce algorithm allowlists, and set expiry. The rest is defense in depth.

If you want to generate a properly random secret right now without writing a script, jwtsecretgenerator.com does it entirely client-side with the Web Crypto API. No accounts, no logs, no network request for the key itself. Just a cryptographically sound secret ready to paste into your secrets manager.

Found a mistake I missed? A 7th pattern that deserves to be on this list? Drop it in the comments — I'll update the post and credit you.

DEV Community: SHAHJAHAN MD. SWAJAN

JWT Security Checklist: 12 Things to Verify Before You Ship

1. Secret Is Generated With a CSPRNG

2. Algorithm Is Explicitly Specified in verify()

3. exp Claim Is Present and Validated

4. iss and aud Claims Are Validated

5. Tokens Are in httpOnly Cookies, Not localStorage

6. HTTPS Is Enforced

7. Refresh Tokens Are Server-Side Revocable

8. The jti Claim Is Used If You Need Immediate Revocation

9. Different Secrets for Each Environment

10. Secret Is Not in Source Code or Version Control

11. Error Messages Do Not Reveal Why Verification Failed

12. Payload Does Not Contain Sensitive Data

What Size JWT Secret Do I Need? Key Length Explained

The Short Answer

Why 256 Bits Is Enough

When to Use 512 Bits

How to Generate the Right Size

What NOT to Use

Bits, Bytes, and Characters Explained

Compliance and Industry Guidance

Testing Your Key Size in Practice

Real-World Scenarios

Verify Your Setup

Related Guides

Summary

I Audited 12 Open Source JWT Implementations and Found the Same 6 Mistakes

Mistake 1 — The Secret Is Literally "secret"

Mistake 2 — jwt.decode() Used in Auth Middleware

Mistake 3 — Algorithm Not Specified in verify()

Mistake 4 — Secret Committed to Version Control

Mistake 5 — Tokens Stored in localStorage

Mistake 6 — Tokens Never Expire

The Pre-Ship Checklist

I Audited 12 Open Source Projects' JWT Implementations and Found the Same 6 Mistakes in All of Them

The 12 Repos: A Quick Note on Scope

Mistake 1 — The Hardcoded Static Secret

Mistake 2 — The algorithm: "none" Attack Surface

Mistake 3 — Secrets Committed to Git

Mistake 4 — Expiration (exp) Not Enforced

Mistake 5 — Signing and Verification With Different Secrets

Mistake 6 — Short Human-Readable Secrets With HS256

The Pre-Ship JWT Checklist

Closing Thought

Mistake 1 — The Secret Is Literally `"secret"`

Mistake 2 — `jwt.decode()` Used in Auth Middleware

Mistake 3 — Algorithm Not Specified in `verify()`

Mistake 2 — The `algorithm: "none"` Attack Surface

Mistake 4 — Expiration (`exp`) Not Enforced