Header Injection
JWT header parameter injection occurs when an attacker manipulates or injects malicious data into the JWT's header section. This vulnerability arises from inadequate validation and handling of JWT header parameters, allowing attackers to exploit or manipulate the token's integrity and authentication.
The below content is based on PortSwigger's JWT attacks module.
Only the alg
header parameter is mandatory, but often there are other parameters as well.
jwk
(JSON Web Key) - Provides an embedded JSON object representing the key.jku
(JSON Web Key Set URL) - Provides a URL from which servers can fetch a set of keys containing the correct key.kid
(Key ID) - Provides an ID that servers can use to identify the correct key in cases where there are multiple keys to choose from. Depending on the format of the key, this may have a matchingkid
parameter.
Via JWK
The below example is based on PortSwigger's JWT authentication bypass via jwk header injection lab.
jwk
is an optional parameter for JWS which servers use to embed their public key directly within the token itself in JWK
format, i.e., a standardized format for representing keys as a JSON object. Typically, servers use a limited whitelist of public keys for JWT signature verification, but they can be misconfigured and use any key that's embedded within the jwt
parameter.



This can be also done manually, but make sure to also change the
kid
parameters; they need to also be matching. The above extension does this automatically.
Via JKU
The below example is based on PortSwigger's JWT authentication bypass via jku header injection lab.
Some servers let you use the jku
(JWK Set URL) header parameter to reference a JWK set, i.e., a JSON object containing an array of JWKs representing different keys. When verifying the signature, the server fetches the relevant key from this URL. JWK Sets are sometimes exposed publicly via a standard endpoint, such as /.well-known/jwks.json
. More secure websites will only fetch keys from trusted domains, but you can sometimes take advantage of URL parsing discrepancies to bypass this kind of filtering.



Via KID
The below example is based on PortSwigger's JWT authentication bypass via kid header path traversal lab.
Servers may use several keys for signing different kinds of data, no just JWTs.
The
kid
parameter identifies which key to use when verifying the signature.The
kid
parameter is just an arbitraty string of the developer's choosing.If
kid
is vulnerable to directory traversal, an attacker could force the server to use an arbitraty file from their filesystem as the verification key.If the server stores its verification keys in a database,
kid
might be vulnerable to SQLi.

Other interesting JWT header parameters
cty
(Content Type) - Sometimes used to declare a media type for the content in the JWT payload. This is usually omitted from the header, but the underlying parsing library may support it anyway. If you have found a way to bypass signature verification, you can try injecting acty
header to change the content type totext/xml
orapplication/x-java-serialized-object
, which can potentially enable new vectors for XXE and deserialization attacks.x5c
(X.509 Certificate Chain) - Sometimes used to pass the X.509 public key certificate or certificate chain of the key used to digitally sign the JWT. This header parameter can be used to inject self-signed certificates, similar to thejwk
header injection attacks discussed above. Due to the complexity of the X.509 format and its extensions, parsing these certificates can also introduce vulnerabilities.
Last updated
Was this helpful?