Long-lived JWT expiry
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
A JWT is issued with a very long expiresIn (years, hundreds of days, or a huge second count), so a leaked token remains usable long after it should have expired.
Why it matters
A JWT issued with an expiry measured in years or hundreds of days is effectively permanent. Because JWTs are typically not checked against a server-side revocation list, a long expiry means a leaked token stays usable for its whole lifetime with no practical way to shut it off. Short access tokens are what limit the blast radius of a leak.
How to fix it
Set access-token expiresIn to minutes (commonly 15m to 1h) and issue a longer-lived refresh token that you store and can revoke server-side. Rotate refresh tokens on use and keep a revocation list or a token-version claim you can bump to invalidate outstanding tokens. Reserve long expiries for tokens you can actually revoke.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo