A JSON Web Token proves who is calling your API, and it only proves that if your server checks the signature, the expiry and the issuer on every request. Most JWT findings come from one of those three checks being skipped or done loosely. Broken authentication sits second in the OWASP API Security Top 10 for 2023, and tokens are where it usually goes wrong.
The signature problems testers still find
Signature verification fails in a handful of well documented ways, and they still appear in production. The first is accepting a token with the algorithm set to none, which some older libraries treat as valid. The second is confusion between HS256 and RS256, where a server expecting an RSA signature is handed a token signed with the public key as an HMAC secret and accepts it. The third is a weak HMAC secret, because a phrase such as the company name will fall to an offline attack in minutes on ordinary hardware. RFC 8725, the current best practice document for JWTs, tells implementers to fix the expected algorithm on the server rather than trusting the header, and that single change removes two of these problems.
Expiry, revocation and the token that never dies
A token your API cannot revoke is a password that changes only when it feels like it. Test what happens after a user is deleted, after a password reset and after an administrator removes a role, because in many applications the old token keeps working until its expiry, and expiry is often set to a year. Refresh token handling is worth the same attention. If a refresh token is not rotated on use, an attacker who captures one keeps a permanent foothold. If it is rotated but the old one is never invalidated, replay works anyway.
“The claim I check first is not the signature, it is the audience. Tokens issued by an internal service for one system get accepted by another system in the same estate more often than people expect, because both trust the same issuer and nobody validated the audience claim. That turns a low privilege application into a key for the finance platform.”
William Fieldhouse, Director, Aardwolf Security Ltd
Where tokens end up being stored
You should treat the storage decision as part of the authentication design, not a front-end detail. A token in browser local storage is readable by any script on the page, which means one vulnerable third-party analytics include is enough to take every session. A token in a cookie with the HttpOnly and Secure flags set, plus SameSite, is out of reach of scripts but needs protection against cross-site request forgery. Mobile applications have their own version of this, where a token written to shared preferences on an unlocked device is trivial to read. An API penetration test looks at all of these paths, since the strongest signing algorithm in the world does not help if the token is sitting in a log file.
Fixing the pattern rather than the finding
Fix the shared library once and every service inherits the improvement. Pin the algorithm, validate the issuer and audience, keep access tokens short-lived at fifteen minutes or less, and give yourself a way to invalidate a session immediately when someone leaves. Then check that the change is real by asking for a retest rather than assuming. When you brief an accredited penetration testing company, ask specifically for token handling to be covered across services, because a per-application scope tends to miss the case where two systems trust each other’s tokens.
Frequently asked questions about JWT security
These come up whenever a development team moves from sessions to tokens.
Are JWTs less secure than session cookies?
No, they are differently secure. Sessions put state on the server and revoke instantly. Tokens remove that lookup and hand you the revocation problem in exchange. Pick the trade you can operate.
Should tokens be encrypted as well as signed?
Only if they carry data you would not want the holder to read. Signing proves the token was not altered. Encryption hides the contents, and it is worth the extra work when claims include personal data.
