jwt

JWT Detection

Overview

A JSON Web Token is a compact container of claims — subject, role, expiry, audience — protected by a signature so the recipient can detect tampering. Applications use it as the session credential itself: whatever the token says about the caller is what the application believes. The flaw class lives at the acceptance site, the moment a request's token is turned into a trusted identity. It fails when the signature is never checked, when the token is allowed to choose its own algorithm or supply its own key, when the signing secret is guessable, or when the claims that bound the token in time and scope are never asserted. The attacker is any client holding one valid token — or merely knowing the token's shape — who wants a token the server never issued; what they gain is impersonation of any user, including administrators, and any entitlement the claims encode. This skill finds such gaps by locating every issuance and acceptance site, verifying each one in parallel, and merging the results into <output_dir>/jwt-results.md.

What it is NOT

• Local credential flows (/websec:authentication): password checking, lockout, reset, and the session lifecycle. If the token is validated correctly but issued too early in a login flow, that is the sibling skill.
• Delegated login flow logic (/websec:oauth): callback validation, state, scope, and account linking. An identity token arriving from a provider is validated here; how the flow delivers it is judged there.
• Outbound request reachability (/websec:ssrf): whether a key-set fetch triggered by a token header can reach internal services. The decision to fetch an address the token names is judged here; note the reachability question there.
• Injection mechanics (/websec:path-traversal, /websec:sql-injection): what a traversal sequence or quote does once a key-identifier value reaches a file path or a query. The trust placed in that header value is judged here; the sink's own class goes under "Also observed".
• What a valid token is allowed to reach (/websec:access-control): a forged or unverified token is this skill's finding. A correctly verified token whose role, tenant, or scope claim was minted from a user-writable profile field is judged here as misplaced trust in the issuing side, and cross-referenced there for the privilege consequence. An endpoint that consults no claim at all before acting is theirs outright. Test: is the token wrong, is the claim wrong, or is nothing checking the claim?
• Data exposure (/websec:information-disclosure): sensitive values carried in a payload that anyone holding the token can read. A signed token is not an encrypted one; that is a data-handling finding, not a forgery one.
• The signing primitive and its parameters (/websec:crypto): the strength of the digest behind a MAC, a symmetric secret's length and randomness source, a constant-time comparison, a certificate check on the client that fetches a key set. Test: is the question which algorithm the token may name, or whether the primitive itself and its parameters are sound? The first is here; the second is theirs.
• The signing key being committed (/websec:secrets): a secret or private key present in source, configuration, a pipeline definition, or a client bundle. Test: the impersonation a guessable or leaked secret enables is judged here; the fact that the value sits in the repository is theirs.
• Not a finding: a service that receives or forwards a token it never verifies, where architecture.md records verification as happening in a gateway or upstream hop. The absence of verification here is the architecture, not a flaw. What is judged in that case: whether this service trusts the token's claims, or an identity header derived from them, without any integrity check of its own — and whether a caller reaching the service directly, bypassing the hop, would be believed. Say which of those you could establish and which needs the gateway's configuration.
• Not a finding: a tampered token that the application correctly rejects; a verification key published at a key-set address while the acceptance site pins its algorithm; a readable payload carrying nothing sensitive; a token used for a non-security purpose that the architecture notes identify as such.