JWT SECURITY CHECKER

What is JWT security testing?

A JSON Web Token is three base64 segments: a header naming the signing algorithm, a payload of claims, and a signature. Your server issues one after login and trusts its claims on every subsequent request. The signature is the entire security model — if it can be forged, skipped, or ignored, then “I am user 1 with role admin” is just a string an attacker types.

Testing JWT handling means checking what the server actually does with a token, not what the code says it does. Does it verify at all? Does it pin the algorithm, or read it from attacker-controlled input? Is the secret guessable? Does the token ever stop being valid? And is it stored somewhere a stray script can read?

This scanner collects the tokens your deployed app issues and answers those questions from the outside.

Why this happens in AI-generated apps

AI coding tools — Lovable, Bolt, v0, Cursor, Replit — produce auth code that works on the first try, which is exactly the problem. A login flow that returns a token and a frontend that stores it looks complete in a preview, and nothing in the preview distinguishes verified from decoded.

The recurring shapes are consistent. Verification helpers that read the algorithm from the token header, because the library’s permissive default was never overridden. Signing secrets that are placeholder strings from an example, kept because the app worked and nobody flagged them. Tokens issued with no exp field, because adding expiry means building a refresh flow and the model took the shorter path. Claims stuffed with the user’s email, name, and role, because it saved a database lookup in the component that needed them. And localStorage.setItem('token', ...), because that is the pattern in the most tutorials.

Each is a reasonable-looking line of code. Together they mean a token that never expires, holds personal data in the open, can be read by any script on the page, and may not be verified at all. See JWT alg=none and kid traversal for the exploitation detail, and OWASP Top 10 for AI-generated code for the surrounding failure modes.

What the scanner checks

How it works

1. Collect — we load your URL in a real headless browser and capture the tokens the app issues and sends.
2. Decode — header and payload are parsed to read the algorithm, expiry, and every claim in the clear.
3. Test the secret — for HMAC tokens, candidate secrets are checked offline against the captured signature.
4. Replay tampered variants — alg=none, algorithm-confusion, and expired tokens are sent to see what the server accepts.
5. Inspect storage — we check where the token lives: cookie flags, localStorage, or sessionStorage.
6. Report — each finding shows the decoded token, what an attacker can forge, and the verification fix.

JWT configuration reference

Common fixes

• Pass the expected algorithm explicitly to your verification call and reject every other value. Never let the token’s own header decide how it is checked — that is the root of both alg=none and algorithm confusion.
• Replace HMAC secrets with a long random value from a secret store, or move to asymmetric signing so services that only verify never hold a key that can mint.
• Set a short exp on every token and build a refresh flow. Without expiry there is no revocation, because a signed token stays valid regardless of what happens to the account.
• Validate iss and aud so a token minted for staging, or for a different service sharing the key, is not accepted in production.
• Keep claims opaque. Carry a user id and look up everything else server-side; the payload is signed, not encrypted, and is readable by anyone who holds the token.
• Move the token into an httpOnly; Secure; SameSite=Lax cookie so JavaScript cannot read it. If it must live in localStorage, keep expiry short and enforce a strict Content-Security-Policy.
• Never trust claims for authorization without a server-side check. A role: admin claim is a hint about who the user says they are, not permission to act.
• Rotate the signing key after fixing anything. Tokens issued under the broken configuration remain valid until the key that signed them is retired.

Related tools and guides

• CORS Misconfiguration Checker — with bearer tokens, a permissive CORS policy is what lets another site use them.
• .env Exposure Checker — a leaked signing secret makes every token in your app forgeable.
• Source Map Exposure Checker — recovered source reveals exactly how tokens are signed, stored, and checked.
• Token Leak Checker — finds JWTs and provider keys shipped in the frontend bundle.
• Supabase RLS Checker — a correctly verified token still needs row-level authorization behind it.
• Security Headers Checker — CSP and cookie flags are what limit the damage of a stolen token.
• Vibe Code Scanner — full security scan of a deployed AI-generated app.
• JWT alg=none and kid traversal pattern — how the bypass is found and exploited in practice.
• Free Security Self-Audit — manual checklist covering auth, tokens, and session handling.