Paste a JWT token and get a security-first audit: detection of alg=none, brute force of an HS256 secret against a dictionary of 50 common secrets, missing claims (exp, iat, aud, iss, jti), suspicious lifetime above 30 days, kid headers with injection-prone characters, unpinned jku and x5u. For pure token reading (claim explainer, expiry countdown, optional HS256 verification) the JWT decoder is the dedicated tool; this audit assumes a valid signature and focuses on the security posture of the configuration.
Typical flow: capture the token from a browser HTTP request (DevTools > Network > Authorization: Bearer... header), or from application logs, or directly from the output of your identity provider during testing.
Three parts separated by dots: header.payload.signature. The tool validates the base64url format and fails with a clear message if any of the three segments is malformed.
Output: decoded header and payload (full text for manual inspection) + security findings list ordered by severity + indicative 0-100 score. Each finding has a normative reference and suggested remediation.
To integrate the report in an audit document or internal ticket: 'Copy report' produces a textual version; browser 'Print' for PDF export (print-optimized CSS hides nav and CTA).
The real risk in JWTs comes from configuration, not format. Reading a token's payload (what the JWT decoder does) is the easy part; asking whether that token is exposed to one of the well-known compromise patterns is what separates a production-grade integration from an incident waiting to happen.
Classic attack vectors checked by the audit. (1) alg=none: historically vulnerable JWT libraries (jsonwebtoken < 8.5, jose < 4 among the most notable) accepted {"alg":"none"} headers, bypassing signature verification. If the backend doesn't explicitly reject this value, an attacker can forge tokens with arbitrary payloads. (2) HS256 with weak secret: HMAC with a shared secret is brute-forcible offline if the secret is a dictionary word; the audit tries a dictionary of 50 common secrets and raises HIGH if one verifies the signature. (3) kid injection: the kid header is used by the backend as key path; if not sanitized it lends itself to path traversal (e.g. ../../../dev/null points to an empty file, the secret becomes the empty string, forgery succeeds) or SQL injection in the keys table. (4) jku/x5u trust: headers that declare the URL of the public key for self-verification; without backend pinning, an attacker controlling that URL controls the key.
Missing claims. RFC 7519 defines optional claims with security value: exp (expiration), nbf (not before), iat (issued at), jti (anti-replay), aud (audience, against confused deputy), iss (issuer, against rogue IdP). A frequent anti-pattern: tokens without exp live forever with no server-side revocation or automatic rotation; without aud, service A can forward a token to service B which accepts it because covered by the same IdP.
Operational limit. The audit does not verify the token signature: that requires the backend key (HS256 secret or RS256 public key). For optional HS256 verification there's the dedicated field of the JWT decoder; for RS256/ES256 verification requires fetching the IdP JWKS, which is the typical scope of the official provider SDK in debug mode. The audit assumes the signature is valid and focuses on configuration risks.
| Check | Severity | Reference |
|---|---|---|
| alg=none / alg=None | Critical | Multiple CVEs (Auth0 lib 2015, jsonwebtoken < 8.5) |
| HS256 with secret in 50 common secrets dictionary | High | OWASP JWT Cheatsheet |
| exp missing | High | RFC 7519 sec. 4.1.4 |
| exp already expired (info) | Info | RFC 7519 |
| iat missing | Low | RFC 7519 sec. 4.1.6 |
| aud missing | Medium | OWASP confused deputy |
| iss missing | Medium | OWASP rogue IdP |
| jti missing | Low | RFC 7519 sec. 4.1.7 (anti-replay) |
| Lifetime > 30 days (exp - iat) | High | OWASP JWT Cheatsheet |
| kid present with suspicious chars (path traversal, SQLi) | Medium | OWASP injection |
| jku present | High | OWASP JWT spec abuse |
| x5u present | High | OWASP JWT spec abuse |
| typ missing | Info | RFC 7519 sec. 5.1 |
Technical terms used on this page, briefly explained.
header.payload.signature, each base64url-encoded. Contains JSON claims about identity or authorization. De facto standard for modern API authentication. alg header indicating no signature. RFC 7518 sec. 3.6 defines it as an option, but OWASP recommends rejecting it at application level to avoid signature bypass. https://idp/.well-known/jwks.json. exp: Unix expiration timestamp. iat: issued at. nbf: not before. All in seconds (not milliseconds). openssl rand -base64 32.kid: "../../../dev/null" -> backend looks up key in filesystem -> finds empty file -> verifies HMAC with secret = empty string. Forgery. (2) kid: "key1' UNION SELECT 'attacker'-- " -> backend SQL on keys table -> SQLi -> attacker-controlled key. Mitigation: treat kid as untrusted input, alphanumeric whitelist + exact lookup in internal map.jku/x5u and use only a hardcoded JWKS endpoint.header.encrypted_key.iv.ciphertext.tag) and the payload is encrypted, not readable without the key. JWT (RFC 7519) is typically signed-only (JWS), the payload is plain base64url. The tool handles classic JWS.exp should be long (typical days-months), (b) jti present for anti-replay (refresh tokens should be invalidated on first use), (c) aud restricted to refresh endpoint, (d) ideally HS256 replaced by RS256 in multi-service arch.This tool flags risks visible from a single token. A professional review covers the full flow: provider configuration, key rotation, refresh tokens, server-side logout, anti-replay (jti), audience binding, kid handling, jku/x5u. PHP, Laravel, Symfony, Node, Python backends.
JWT architecture review7-question wizard, 2 minutes, free. Output: range of person-days, rough price range, engagement recommendation. Reference rate 300 EUR/day. Built for custom backend projects, integrations, security audits or AI automation.
Get a free quote