Fix guide · info · jwt_expired_in_client

Expired JWT hardcoded in client bundle

What this rule means

A JWT in your client bundle has an exp claim in the past. The token is currently useless to attackers, but its presence indicates a hardcoded fixture that survived the build — usually a test artefact that points at a live token elsewhere.

Why it matters

Expired tokens aren't a direct vulnerability — your backend should reject them. The reason this is flagged at all is that the surrounding pattern usually contains a live token too. Dev environments often have a TEST_USER_TOKEN, a STAGING_ADMIN_TOKEN, and a LIVE_FALLBACK_TOKEN constant block; if one is in the bundle, the others probably are too.

Treat this as a cleanup signal, not an emergency.

How to fix it

  1. Find the surrounding constant. grep -B5 -A5 "<first-12-chars>" src/ will surface the file and show what other tokens are nearby.
  1. If any of those other tokens are still valid (decode and check exp), treat the live one as exposed — see jwt_admin_in_client or jwt_no_expiration depending on its claims.
  1. Move the test fixtures out of src/ into test/fixtures/ or scripts/, and verify your bundler isn't pulling files from those directories into the production build (vite and webpack should both exclude them by default; check your config if you've customised it).

Full guide: /blog/jwt-mistakes-vibe-coded.

Did vibecheck flag this on your app?

If you reached this page from a vibecheck inspection report, the redacted match in your scan output is the exact string we found in your bundle. After applying the fix above, run the inspection again — the finding should clear.

Run another inspection

Related fix guides