JWT Security Auditor
Audit JWT tokens for algorithm vulnerabilities, missing claims, excessive expiration, and sensitive data exposure
Enter a JWT token (header.payload.signature) to audit for security issues
What is the JWT Security Auditor?
The JWT Security Auditor is a client-side tool that inspects JSON Web Tokens for common security vulnerabilities. It analyzes the token header for algorithm weaknesses, the payload for missing or dangerous claims, and reports a security score based on detected issues — all without transmitting your token anywhere.
How to Use
- Paste your JWT token into the input field
- Click "Audit" or wait for automatic processing
- Review the header and payload decoded content
- Check the security findings with severity ratings
- Follow the recommendations to improve token security
Example: Insecure JWT Token
This token uses alg=none and has no expiration — critical vulnerabilities:
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwicGFzc3dvcmQiOiJzZWNyZXQxMjMifQ.What Security Issues Are Detected?
- Algorithm: none — Token has no cryptographic signature, can be forged
- Weak HMAC algorithms — HS256/HS384/HS512 use shared secrets, risking exposure
- Missing expiration (exp) — Token never expires, persistent access if compromised
- Missing issuer (iss) — Cannot verify which service created the token
- Missing audience (aud) — Token can be replayed to unintended services
- Excessive expiration — Tokens valid for more than 24 hours increase attack window
- Sensitive data in payload — Passwords, API keys, or PII in Base64-encoded claims
Security Scoring
Each token receives a score from 0 to 100. Critical issues (alg=none, sensitive data) deduct 25 points, High issues (weak algorithm, missing exp) deduct 15 points, Medium (missing iss, aud) deduct 8 points, and Low (missing nbf) deduct 3 points. Grades: A (90+), B (75+), C (60+), D (40+), F (below 40).
JWT Security Best Practices
- Use asymmetric algorithms (RS256, ES256, PS256) for better key management
- Always include exp with short-lived access tokens (15 min to 1 hour)
- Use refresh tokens for long sessions instead of long-lived access tokens
- Include iss and aud claims to prevent token misuse
- Never store secrets, passwords, or PII in JWT payloads — use JWE if needed
- Validate tokens server-side on every request, not just at login
Privacy and Security
All analysis happens entirely in your browser using JavaScript. Your JWT tokens — which often contain authentication credentials and personal claims — are never transmitted to any server. No data is stored, logged, or shared.
Frequently Asked Questions
What does the JWT Security Auditor check?
The auditor inspects JWT tokens for algorithm vulnerabilities (alg=none, weak symmetric algorithms), excessive expiration times (tokens valid for more than 24 hours), missing standard claims (exp, iss, aud, nbf), and sensitive data exposure in the payload (passwords, API keys, PII).
How is the security score calculated?
The score starts at 100 and deducts points based on finding severity: Critical issues (alg=none, sensitive data in payload) deduct 25 points, High issues (weak algorithm, missing exp, excessive expiration) deduct 15, Medium (missing iss, aud) deduct 8, and Low (missing nbf) deduct 3. The final score maps to a letter grade (A: 90+, B: 75+, C: 60+, D: 40+, F: below 40).
Is my JWT token sent to a server?
No. All analysis happens entirely in your browser using JavaScript. Your JWT token never leaves your device and is not stored or transmitted. This is critical because JWT tokens often contain authentication credentials and personal information.
Why is alg=none flagged as critical?
When the algorithm is set to 'none', the token has no cryptographic signature. This means anyone can forge tokens by simply editing the payload and removing the signature. This is a well-known JWT attack vector where an attacker strips the signature and sets alg to none.
Why are HMAC algorithms (HS256, HS384, HS512) flagged?
HMAC algorithms use a shared secret for signing and verification. If the secret is compromised, any party with access can forge tokens. Asymmetric algorithms (RS256, ES256, PS256) use separate private/public keys, so only the issuer can sign tokens while anyone can verify them.
What is excessive expiration?
The auditor flags tokens with an expiration time exceeding 24 hours. Long-lived tokens increase the attack window if compromised. Best practice is to use short-lived access tokens (15 minutes to 1 hour) combined with refresh tokens for longer sessions.
Why should I not store sensitive data in JWT payloads?
JWT payloads are Base64URL-encoded, not encrypted. Anyone with access to the token can decode and read the payload. Never include passwords, API keys, credit card numbers, or other secrets. Use JWE (JSON Web Encryption) if you need to include sensitive claims, or store sensitive data server-side.
What claims should every JWT include?
At minimum, include 'exp' (expiration time) to prevent indefinite token validity, 'iss' (issuer) to verify the token source, and 'aud' (audience) to restrict which services accept the token. Adding 'nbf' (not before), 'iat' (issued at), and 'jti' (unique ID) provides additional security.
What is the maximum input size?
The tool warns when input exceeds 500KB and rejects input larger than 5MB. Most JWT tokens are well under 10KB. Tokens approaching or exceeding these limits likely have architectural issues and should be reviewed.