Format String in Adonisjs with Jwt Tokens

A format string vulnerability occurs when user-controlled input is passed directly to a function that treats the input as a format string, such as printf-style functions. In AdonisJS, this risk can intersect with JWT token handling when token values or claims are improperly interpolated into logging, error messages, or dynamic function calls. If an attacker can influence the content of a JWT—either by supplying a malicious token or by tricking the application into incorporating token data into a format string—they may cause the application to read from or write to memory, potentially leaking sensitive information or causing erratic behavior.

Consider a scenario where an endpoint decodes a JWT and then logs its claims using a format string that includes user-controlled data. If the logging utility uses printf-style formatting and the developer does not sanitize or parameterize the input, an attacker can supply format specifiers (e.g., %s, %x, %n) within the token payload or related data. These specifiers can cause the logging function to read stack contents, leading to information disclosure of secrets or internal state. Similarly, if token data is used in error messages or passed to functions that evaluate templates, the application may expose internal paths, variable values, or other sensitive context.

In AdonisJS, JWTs are commonly handled via the jsonwebtoken package or AdonisJS provider integrations. When tokens are parsed and claims are extracted, developers must avoid directly embedding token fields into format strings, template literals that are later used in logging or messaging, or dynamic function calls. Even seemingly benign operations, such as constructing a debug message that includes a user ID from the token, can become dangerous if the formatting is not controlled. For example, using Node.js console.log with unsanitized input that includes format specifiers can trigger unintended reads if the underlying implementation uses printf-style formatting.

The intersection of format string issues and JWT tokens is particularly concerning because JWTs often carry identity, role, or scope information that an attacker may try to manipulate or expose. A token that includes a username or email could be crafted to include format specifiers, and if those values are later used in logging or error reporting, the application may inadvertently leak sensitive data or crash. This can aid further attacks by revealing system details or enabling denial of service through malformed input.

To contextualize the risk, this does not involve code execution in the sense of running arbitrary commands, but it can lead to information disclosure and instability. The key is to treat all data derived from JWTs as untrusted and to avoid any form of direct string interpolation into functions that perform formatting. Instead, use structured logging with explicit fields, validate and sanitize claims, and ensure that any messaging or error generation uses parameterized strings or safe serialization methods.

Remediation focuses on ensuring that JWT token data is never used as a format string and that any logging or message construction is performed safely. Below are concrete examples for AdonisJS applications that use JWTs for authentication.

1. Safe logging of JWT claims without format string interpolation:

import { BaseTokenPayload } from '@ioc:Adonis/Addons/Auth'
import Logger from '@ioc:Adonis/Core/Logger'

function logTokenClaims(tokenPayload: BaseTokenPayload) {
  // Safe: structured log with explicit fields, no format string interpolation
  Logger.info('Token validated', {
    userId: tokenPayload.sub,
    role: tokenPayload.role,
    exp: tokenPayload.exp,
  })
}

2. Avoiding format specifiers when constructing error or debug messages that include token data:

import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'
import { schema } from '@ioc:Adonis/Core/Validator'

export default class AuthController {
  public async validateToken({ request, response }: HttpContextContract) {
    const token = request.input('token')
    // Validate token structure safely without embedding into format strings
    const validationSchema = schema.create({
      token: schema.string(),
    })

    const validated = await request.validate({ schema: validationSchema })

    // Safe: use template literals only for concatenation, not formatting with specifiers
    Logger.debug(`Token received, length: ${token.length}`)

    response.ok({ message: 'Token processed safely' })
  }
}

3. Using parameterized approaches when token data must be included in messages:

import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'

export default class TokenController {
  public handleTokenContext({ request }: HttpContextContract) {
    const token = request.qs()['token'] || ''
    // Safe: no format specifiers like %s or %x in string construction
    const safeMessage = ['Token context:', token].join(' ')
    Logger.info(safeMessage)
  }
}

4. Ensuring JWT parsing libraries are used with default options and not exposed to user-controlled format strings:

import { createMiddlewareClient } from '@ioc:Adonis/Addons/Auth'

export default class AuthMiddleware {
  public async handle(ctx: HttpContextContract, next: () => Promise) {
    const jwt = createMiddlewareClient({ ctx })
    const payload = jwt.verify()

    // Safe: use payload fields as data, not as format strings
    ctx.logger.info('JWT verified', { subject: payload.subject })

    await next()
  }
}

These examples emphasize strict separation between data and formatting. In AdonisJS, prefer structured logging, explicit field extraction, and validation schemas to ensure JWT token data is handled safely and cannot be used to exploit format string vulnerabilities.