OWASP JWT: brute-force 10,000 secrets + kid injection

The real risk in JWTs comes from configuration, not from the format. Reading the payload of a token (what the JWT decoder does) is the easy part: asking whether that token is exposed to one of the known compromise patterns is what separates a production-grade integration from an incident waiting to happen. Historical CVEs on widely-used JWT libraries (jsonwebtoken < 8.5, jose < 4, python-jwt, ruby-jwt) all stem from implicit backend assumptions that this tool surfaces from the token's manifest alone.

The four classical vectors verified by the audit. (1) alg=none and permutations: historically vulnerable libraries accepted {"alg":"none"} bypassing signature verification. The check covers the exact string and all case-mix permutations (None, NONE, nULL, null, empty alg, numeric alg, missing alg). (2) HS256 with weak secret: HMAC with a shared secret is brute-forceable offline if the secret is a human passphrase. The audit tries a curated dataset of 10,000 known secrets (wallarm/jwt-secrets + SecLists/scraped-JWT-secrets, recompiled nightly), verifying each candidate via local WebCrypto HMAC-SHA256. (3) alg confusion attack: the backend is configured for RS256 but also accepts HS256, and uses the RSA public key as the HMAC secret. Documented vector in historical CVEs (jsonwebtoken pre-8.5). If you provide the public key, the tool tries HMAC verification using the pubkey as secret and reports critical if it passes: it means the backend would accept attacker-controlled tokens signed with its own public key (which is public by definition). (4) kid injection / jku-x5u abuse: headers that declare which key to use for verification. If the backend doesn't sanitize them (kid used as key path or SQL lookup) or doesn't pin them to trusted domains (jku/x5u), an attacker who controls the input controls the key.

Missing claims. RFC 7519 defines optional claims with concrete security value: exp (expiration, time bound), nbf (not before, activation delay), iat (issued at, emission timestamp), jti (JWT ID, anti-replay), aud (audience, mitigation against confused deputy), iss (issuer, mitigation against rogue IdP). Frequent anti-pattern: tokens without exp, living forever with no server-side revocation; or without aud, where service A can forward the token to service B that accepts it because they share the same identity provider, even if it wasn't intended for B.

Esoteric headers. Two lesser-known headers the tool flags as info: cty (content type, enables nested JWT - a JWT inside a JWT, a confusion vector if the backend unwraps without re-authenticating), zip (compression: the header {"zip":"DEF"} enables DEFLATE decompression of the payload, and has been a vector for zip-bomb attacks against libraries that didn't limit output size).

Operational privacy. A JWT token contains the user-claim payload and the signature configuration in the header: in real audits you don't want to upload it to a third-party service, even over TLS. Here no network request leaves with token data. The secrets dataset (10,000 entries, ~180 KB raw) is downloaded by the browser only on first use and cached in localStorage for subsequent sessions (automatic invalidation via SHA-256 over the public file). Audit, JWT parsing, HMAC verification, secret brute-force, pubkey reading: all local via the WebCrypto API.

When static triage is the right level. Typical scenarios. (a) Preliminary review of a legacy API without backend access: you captured a token from the frontend and want to know if the server-side configuration is solid. (b) Pre-engagement audit to estimate the cost of a possible JWT hardening contract before quoting. (c) Initial screen before a serious cyber assessment: the high/critical list deserves deeper exploitability assessment, mapping of verify codepaths in the backend, verification of the algorithm whitelist and JWKS pinning. (d) Periodic self-check by the API owner who wants to know whether the integration was done properly.

Scope limit. The audit does not replace: an architectural review of the full flow (key rotation, refresh token rotation, server-side logout with jti blacklist, audience binding, kid and jku/x5u handling in production, OIDC provider configuration); static analysis of the verify code in the backend (algorithm whitelist, exp leeway, exception handling); the application-specific threat model. It is a triage and presents itself as one.

The audit applies 18 checks across 4 families. All checks run locally in the browser via WebCrypto (for HMAC verifications) and pure JSON parsing for the rest.

Family 1 - Algorithm (4 checks). alg_none verifies the exact string none in any case. alg_permutation covers malicious variants: empty alg, numeric alg, JSON null, NULL/None/NoNe/nULL. alg_confusion_confirmed (requires optional pubkey): if the token is HS256 and the user provided an RSA public key, the tool attempts HMAC-SHA256 verification using the pubkey as secret. If verification passes, the backend accepts HS256 tokens signed with its own public key. Vector confirmed. weak_secret: Audit button tests against the fast tier (1,000 common secrets, <1s); Deep audit button tests against the full tier (10,000 additional secrets, 5-10s).

Family 2 - Header esoterics (4 checks). kid_suspicious: the kid value contains characters typical of path traversal (../) or SQLi (UNION, SELECT, OR, AND, --, '). jku_present and x5u_present: headers declaring an external public key URL; without whitelist pinning, the attacker who controls the URL controls the key (HIGH). typ_missing: absence of typ, recommended by RFC 7519 sec. 5.1. cty_present and zip_present: headers enabling nested JWT and DEFLATE, flagged INFO for manual codepath inspection.

Family 3 - Payload claims (8 checks). For each relevant RFC 7519 claim: presence, format, value. exp_missing: token without expiration (HIGH). exp_expired: expiration in the past (INFO, active mitigation). exp_far_future: exp > 1 year in the future (MEDIUM). iat_missing: missing issued-at (LOW). lifetime_too_long: exp - iat > 30 days (HIGH, configurable). aud_missing: no audience binding (MEDIUM, confused deputy). iss_missing: no issuer (MEDIUM, rogue IdP). jti_missing: no anti-replay ID (LOW).

Family 4 - HS256 brute-force (1 check, 2 modes). Implementation: the browser imports each candidate via crypto.subtle.importKey as an HMAC key, then verifies the header.payload segment signature via crypto.subtle.verify against the token's signature. Sequential (HMAC-SHA256 on small input does not benefit from browser parallelism). Typical throughput: 1,000-2,000 verifies/second on a modern laptop. Fast tier 1,000 secrets = sub-second. Full tier 10,000 secrets = 5-10 seconds. The dataset is recompiled nightly by shared/cron/build_jwt_secrets_db.php via union(wallarm, SecLists), case-insensitive dedup, capped at 10,000 entries (the 90,000+ long tail is dropped: after the first 10k the additional match rate is marginal and browser cost doesn't justify it).

Atomic publication. The cron job applies an atomic multi-file write: tier files are written to temporary files, renamed one by one, and the index.json with new SHA-256s is the last file renamed. If the process dies mid-way, clients keep reading the previous dataset. Never partial dataset. If upstream sources fail, the job aborts without publishing: better a one-day-old dataset than an incomplete one.

Aggregated score 0-100. Computed as 100 - sum(severity_weights), with weights: critical 50, high 20, medium 10, low 5, info 0. Reading: 80-100 green (reasonable posture), 50-79 yellow (interventions plannable), 0-49 red (significant risk, some vectors require immediate mitigation). The score does not measure overall backend quality, only the single token's posture against known OWASP/CVE patterns.

Finding severity. critical: confirmed vector enabling forgery or signature bypass directly (alg=none accepted, alg confusion verified, HS256 secret found in dataset). Immediate mitigation. high: probable but unconfirmed vector from manifest alone (jku/x5u without backend pinning verifiability, weak secret in untested tier, lifetime too long, exp missing). Investigate and mitigate in current sprint. medium: suboptimal practice that reduces defense in depth (aud/iss missing, kid suspicious, exp far future). Hardening backlog. low: missed best practice (iat/jti missing). Cleanup when convenient. info: observational state (typ missing, exp expired, cty/zip present). Reporting only.

What to do, by priority. (1) alg=none / alg permutation CRITICAL: the backend must explicitly reject any alg outside a whitelist (HS256, RS256, ES256). Immediate patch, regression tests with malformed tokens. (2) alg confusion confirmed CRITICAL: the backend must use APIs with algorithm-specific verification (e.g. jwt.verify(token, key, { algorithms: ['RS256'] }) in jsonwebtoken), not auto-detect from the header. (3) weak secret HIGH/CRITICAL: rotate the secret immediately to a crypto-safe random string of 32+ bytes (openssl rand -base64 32) and invalidate all tokens in circulation. (4) jku/x5u HIGH: the backend must pin the URL to a whitelist or ignore these headers entirely and use a hardcoded JWKS endpoint only. (5) kid suspicious MEDIUM: validate kid against an alphanumeric whitelist, exact lookup in an internal map, never use it as an SQL query parameter or a file path. (6) missing claims: add exp, aud, iss, jti to the token-emission template. Validate server-side with reasonable leeway (5-30 seconds).

Alg confusion finding format. When the check passes with the provided pubkey, the finding reports: the token, the public key used as secret, the algorithm declared in the header, a textual description of the vector. Hand it to the team with the operational message: "the backend must verify the token with the specifically expected algorithm, not the one declared in the header. Suggested patch: constrain the algorithm in the verify signature, or reject HS256 at the application level if the architecture uses RS256".