← mohdarif.com

Web Security · Authentication

JWT Security: Attacks and Server-Side Validation

What goes wrong when an API trusts a JWT, shown attack by attack, with the server-side fix for each.

By Mohammad Arif · 12 min read

Most JWT vulnerabilities come from two root causes: the server lets the token decide how it gets verified, or the server treats a valid token as permission to do anything. The attacks below follow the order a request is processed: parse the header, pick a key, verify the signature, check the claims, authorize the action. After that come secure token storage, refresh token rotation, and the server-side validation steps that tie it together.

1. Anatomy of a JWT

A JWT is three Base64URL strings joined by dots: header.payload.signature.

eyJhbGciOiJSUzI1NiIsImtpZCI6ImtleS0yMDI2LTAyIiwidHlwIjoiSldUIn0
.eyJpc3MiOiJodHRwczovL2xvZ2luLmV4YW1wbGUiLCJzdWIiOiJ1c2VyLTQyIiwiYXVkIjoib3JkZXJzLWFwaSIsInNjb3BlIjoib3JkZXJzOnJlYWQiLCJleHAiOjE5MDAwMDAwMDB9
.<signature bytes>

// header: tells the verifier how the token was signed
{ "alg": "RS256", "kid": "key-2026-02", "typ": "JWT" }

// payload: the claims
{ "iss": "https://login.example",  // issuer
  "sub": "user-42",                // subject (who)
  "aud": "orders-api",             // audience (which API it is for)
  "scope": "orders:read",
  "exp": 1900000000 }              // expiry (unix time)

The important point for everything below: the header is written by whoever sends the token. Every header field is attacker-controlled input.

2. Where JWTs fit, and where they don't

A session cookie is a random ID that the server looks up on every request. A JWT carries its claims and is checked with a signature, so no lookup is needed.

A common design is a short-lived JWT access token (5 to 15 minutes) paired with a server-tracked refresh token. Verification stays fast, and you can still cut an account off.

3. Attacks, in the order a request is processed

3.1alg: none (unsigned tokens)

alg names the signing algorithm. The spec defines none for tokens with no signature. Early libraries honored it, so an attacker could remove the signature and edit any claim.

// forged header, empty signature
{ "alg": "none", "typ": "JWT" }
{ "sub": "user-42", "role": "admin" }
eyJhbGciOiJub25lIn0.eyJzdWIiOiJ1c2VyLTQyIiwicm9sZSI6ImFkbWluIn0.

Mitigation

Pass an explicit algorithm allowlist to the verify call (algorithms=["RS256"]). Never derive the algorithm from the token. Reject any token with none, and some libraries also need case variants like None blocked.

3.2Algorithm confusion (RS256 → HS256)

RS256 verifies with a public key. HS256 verifies with a shared secret. If the server calls verify(token, key) and lets the header choose the algorithm, an attacker switches the header to HS256 and signs the token using the server's public key as the HMAC secret. The public key is, by design, public.

# vulnerable: algorithm comes from the token
jwt.decode(token, PUBLIC_KEY)

# attacker side: sign HS256 with the public key bytes
header  = {"alg": "HS256", "typ": "JWT"}
forged  = hmac_sha256(key=PUBLIC_KEY_PEM, msg=b64(header) + "." + b64(payload))

Mitigation

Use the same fixed allowlist, and bind each key to one algorithm. Modern libraries (jose, PyJWT 2.x) refuse to use a PEM public key as an HMAC secret, but older versions and custom code may not, so test for it.

3.3Weak HMAC secret

HS256 tokens are verified with a shared secret. If it is guessable (secret, changeme, the app name), the attacker takes one token they received legitimately and brute-forces the secret offline with hashcat (-m 16500). No requests reach your server during the attack. Once cracked, they can mint any token.

Mitigation

Generate at least 256 random bits, store it in a secrets manager, and rotate it. Where several services only need to verify, use RS256 or ES256 so that a leak of a verifying service cannot be used to issue tokens.

openssl rand -base64 48

3.4kid injection

kid (key ID) is a label that tells the verifier which key signed the token. It matters when an issuer rotates keys and publishes several at once. Example header: { "alg": "RS256", "kid": "key-2026-02" }.

The flaw is in how the server uses it. If kid is placed into a SQL query or a file path, the attacker controls the lookup.

# vulnerable: SQL injection through kid
key = db.query(f"SELECT secret FROM keys WHERE id = '{header['kid']}'")

# attacker header: the UNION returns a value they chose, then they sign HS256 with it
{ "alg": "HS256", "kid": "x' UNION SELECT 'AAAA' -- " }

# vulnerable: path traversal through kid
key = open(f"/keys/{header['kid']}").read()

# attacker header: points at a file with known content (empty), sign with empty secret
{ "alg": "HS256", "kid": "../../../../dev/null" }

Mitigation

Treat kid as a lookup key into a set you already trust, never as a query or path fragment.

KEYS = load_jwks_from_config()          # {"key-2026-02": <public key>, ...}
key = KEYS.get(header.get("kid"))       # dict lookup, nothing is interpolated
if key is None:
    reject()

3.5jku: attacker-hosted key set

jku (JWK Set URL) is a header that points to a URL where the verifier can download the signing keys. The attacker sets it to their own server, hosts a key pair they generated, and signs the token with their private key. A server that follows the URL verifies a forged token successfully.

{ "alg": "RS256",
  "kid": "attacker-key",
  "jku": "https://evil.example/jwks.json" }   // attacker's JWKS, attacker's key

The same field is an SSRF primitive: "jku": "http://169.254.169.254/latest/meta-data/" makes the server send a request to an internal address. Weak allowlists (substring checks, https://login.example@evil.example, open redirects on the trusted host) get bypassed.

Mitigation

Ignore jku entirely. Fetch keys from one JWKS URL taken from your own configuration (or the issuer's discovery document), cache it, and look keys up by kid. If you must honor a header URL, compare it to an exact-match allowlist after parsing, and block private IP ranges on the outbound fetch.

3.6jwk: key embedded in the token

jwk carries the public key inside the header itself. The attacker generates a key pair, embeds the public half, signs with the private half, and the token verifies against the key it brought. This was the root of CVE-2018-0114 in the node-jose library.

{ "alg": "RS256",
  "typ": "JWT",
  "jwk": { "kty": "RSA", "e": "AQAB", "n": "<attacker's public modulus>" } }

Mitigation

Never verify against a key supplied by the token. Related fields (x5c, x5u) have the same problem. Trusted keys come only from your issuer configuration.

3.7Missing or loose claim validation

A valid signature only says a trusted issuer signed these claims. It does not say they are meant for your API.

• No aud check: a token issued for billing-api is accepted by orders-api. This enables cross-service token reuse.
• No iss check: a token from another tenant or environment (staging key, same format) is accepted.
• No exp check, or a very long lifetime: stolen tokens stay useful for days.
• Token type confusion: an ID token or refresh token accepted where an access token is required. Check typ (at+jwt for RFC 9068 access tokens).

Mitigation

Require iss, aud, exp and sub to be present, match iss and aud exactly, and allow only a small clock-skew leeway.

3.8Valid token, wrong permission (broken authorization)

This is the most common real-world flaw because every earlier check can pass. A token with scope: orders:write says the caller may write orders in general. It does not say they may cancel order 42, which belongs to another customer. This is broken object level authorization (BOLA / IDOR), number one on the OWASP API Security Top 10.

Mitigation

Use the token to learn who is calling. Then check the specific resource against current data on every request: tenant, ownership, state, and permission.

3.9Token theft and long-lived tokens

A bearer token works for whoever holds it. If it is stolen through XSS, a leaked log, a proxy, or a compromised device, the server cannot tell the thief from the user, and a JWT stays valid until exp. You cannot make theft impossible, so the design goal is to limit how long a stolen token is useful and to detect the theft. Sections 4 and 5 cover how.

4. Storing tokens securely

Where the client keeps the token decides who can steal it.

Recommended pattern for a browser app

• Access token: short-lived (5 to 15 minutes), held in memory, sent in the Authorization: Bearer header.
• Refresh token: in an HttpOnly cookie scoped to the refresh endpoint only, so it is not sent with every request.

Set-Cookie: refresh_token=<opaque random value>;
            HttpOnly; Secure; SameSite=Strict;
            Path=/auth/refresh; Max-Age=1209600

• HttpOnly: JavaScript cannot read it.
• Secure: sent over HTTPS only.
• SameSite=Strict (or Lax): the browser withholds it on cross-site requests, which blocks most CSRF. Add a CSRF token or an Origin header check on the refresh endpoint as a second layer.
• Path=/auth/refresh: limits where the cookie is sent.

Other clients

• Mobile: iOS Keychain or Android Keystore, never plain preferences or app files.
• Server-to-server: secrets manager or environment injection. Never commit tokens or signing keys to source control.
• Signing keys: kept in a KMS or HSM where possible, so the key material is never on application disks.

5. Refresh token rotation

Short-lived access tokens are only practical if the client can get new ones without logging in again. That is the job of a refresh token: a long-lived credential used only at the token endpoint. Because it lives longer, it is the more valuable target. Refresh token rotation reduces that risk.

How it works

1. On login, the server issues an access token (JWT, 10 minutes) and a refresh token (opaque random string, not a JWT) and starts a token family: a record that ties every refresh token descended from this login together.
2. When the access token expires, the client sends the refresh token to /auth/refresh.
3. The server checks it, then returns a new access token and a new refresh token. The old refresh token is marked used and can never be accepted again.
4. The chain continues: login → R1 → R2 → R3 → … All belong to one family.

Family F1:   R1 ──used──▶ R2 ──used──▶ R3 (current)
                │
                └─ if R1 shows up again after R2 was issued → reuse detected

Reuse detection

Suppose an attacker steals R1 while the real user also holds it. Whoever refreshes first gets R2, and R1 becomes used. Then the other party presents R1.

• Attacker refreshes first: the real user's next refresh sends the already-used R1. The server sees a used token replayed.
• User refreshes first: the attacker's stolen R1 is rejected.

In both cases, a used refresh token appearing again means two parties hold the same chain, so the server revokes the entire family. The attacker's current token dies, the user is forced to log in again, and the event is logged as a likely theft.

Why this method is useful

• Limits the damage window. A stolen access token expires in minutes. A stolen refresh token works once, and only until the next legitimate refresh.
• Detects theft. A static long-lived token gives no signal when it is copied. Rotation turns replay into an alarm.
• Gives real revocation. The server holds state for refresh tokens, so logout, password change, and account disable can kill a whole family immediately, while access-token verification stays stateless.
• Keeps the fast path fast. API calls only check a signature. The database is touched only at refresh time.

Implementation notes

• Store only a hash of each refresh token (SHA-256 is fine for high-entropy random values), with its family ID, status, and expiry. A database leak then does not expose usable tokens.
• Use at least 256 bits of randomness from a CSPRNG.
• Set an idle timeout and an absolute lifetime for the family (for example 30 days), so a chain cannot be extended forever.
• Make the "check, mark used, issue next" step atomic (a single transaction or conditional update). Otherwise two simultaneous requests can both succeed.
• Multiple tabs or a retry after a network drop can look like reuse. A short grace window (a few seconds) for the immediately previous token avoids logging out honest users, at the cost of a small replay window.
• Bind the family to the client where possible (client ID, and device or IP signals for risk scoring).
• This is what OAuth 2.0 Security Best Current Practice recommends for public clients, and what major identity providers implement as "refresh token rotation".

6. Server-side validation, step by step

Every API request that carries an access token goes through the same checks, in this order. Each step closes one of the attacks in section 3.

1. Bound the input. Require Authorization: Bearer, cap the token size, and reject tokens in query strings. (3.9)
2. Select the key from configuration. Use the JWKS URL from your own settings or the issuer's discovery document, cache it, and pick the key by kid with a plain lookup. Ignore jku, jwk, x5u and x5c. (3.4 to 3.6)
3. Verify the signature with a fixed algorithm. The allowlist lives in server code. Reject none and any algorithm that does not match the key. (3.1 to 3.3)
4. Validate the claims. Exact match on iss and aud, require exp (and sub), apply a small clock-skew leeway, and check the token type. (3.7)
5. Authorize the action. Load the resource and check tenant, ownership, state and permission, using current data rather than only the token's roles. Return 404 for objects the caller should not know exist. (3.8)
6. Fail closed and quietly. Any failure returns the same generic 401 or 403, with details in server logs only (never the token itself).

Use a maintained JOSE library for steps 2 to 4 rather than parsing tokens by hand. Most of the bugs in section 3 come from custom JWT handling.

7. Quick reference

8. Testing it

For a code review or pentest, these checks cover the list above:

• Send the token with alg: none and with the signature removed. Both must return 401.
• Switch RS256 to HS256 and sign with the public key (Burp's JWT Editor extension or jwt_tool -X k).
• Crack the secret of any HS256 token with hashcat and a wordlist.
• Fuzz kid with quotes, ../ and null bytes. Add jku and jwk headers pointing at a server you control and watch for inbound requests.
• Replay a token against a different API or environment, and send one with an expired exp.
• With a valid low-privilege token, request another user's resource IDs.
• Use a refresh token twice. The second use must fail and the whole family must be revoked.
• Check where tokens live: browser storage, cookie flags, URLs, logs, and error messages.

9. Pre-ship checklist

• Algorithm allowlist is set in code, and none is rejected.
• Keys come from configuration, selected by kid lookup only. jku, jwk, x5u, x5c are ignored.
• HMAC secrets are 256+ random bits, or the system uses asymmetric signing.
• iss and aud match exactly. exp is required and lifetimes are short.
• Every endpoint checks permission on the specific resource.
• Access tokens expire in minutes. Refresh tokens are opaque, stored hashed, rotated on every use, with reuse detection and an absolute lifetime.
• Key rotation and compromise response are defined and tested.
• Tokens are absent from URLs and logs. Access token in memory, refresh token in an HttpOnly, Secure, SameSite cookie with CSRF controls.

References

• RFC 7519: JSON Web Token
• RFC 7515: JSON Web Signature (defines alg, kid, jku, jwk, x5u, x5c)
• RFC 8725: JWT Best Current Practices
• RFC 9068: JWT Profile for OAuth 2.0 Access Tokens
• OWASP JWT Cheat Sheet
• PortSwigger Web Security Academy: JWT attacks