JWT Token Security Check: What StackShield Tests

What this check looks for

Where your application issues JSON Web Tokens, StackShield inspects how they are signed and configured. It looks for the signature algorithm, whether tokens can be presented with their algorithm downgraded to none, and signals of overly long or non-expiring lifetimes.

A JWT is only as trustworthy as its signature. The check is reading whether that signature can be forged or bypassed.

Why it matters

A JWT carries claims your application trusts: who the user is, what they can do. If the token can be forged, every one of those claims can be set by an attacker. The classic failures are an unverified none algorithm, where the server accepts an unsigned token, and a weak or leaked signing secret that lets an attacker mint their own valid tokens.

Long lifetimes make it worse. A token that never expires is a permanent credential; if one leaks through a log, a referrer header or a compromised device, it stays valid indefinitely because there is no revocation and no expiry to save you.

What a failed check means

A failed check means your token handling has at least one of these weaknesses: a forgeable signature, an accepted none algorithm, or lifetimes long enough that a leaked token is a lasting liability. Any of these turns authentication into something an attacker can assert rather than something they have to prove.

The fix is a strong signing secret, an explicitly pinned algorithm, short access-token lifetimes with refresh, and a revocation path.

See the step-by-step remediation: how to fix this.