Request Smuggling in Adonisjs with Jwt Tokens

Request smuggling occurs when an application processes the same request differently depending on whether it passes through an intermediary (such as a proxy, load balancer, or API gateway) versus the origin server. In AdonisJS applications that use JWT tokens for authentication, this can arise from inconsistent parsing and validation of requests between the edge and the application layer, and from trust placed in JWT-derived metadata.

When JWT tokens are used, the typical flow is: the client sends an HTTP request with an Authorization header containing a Bearer JWT; an edge proxy or API gateway may perform its own routing or rewriting; then the request reaches the AdonisJS application, which authenticates via the JWT middleware. If the proxy and the application differ in how they parse headers, handle Content-Length, or interpret the presence/absence of a body, an attacker can craft a request that the proxy interprets as one operation (e.g., a public route) while the application interprets as another (e.g., an authenticated admin operation).

Specifically, AdonisJS applications that rely on JWT middleware (e.g., using the official adonisjs/jwt package) may inadvertently expose smuggling surfaces when they trust headers that a preceding hop has already processed. For example, if the application uses X-Forwarded-For or other forwarded headers to make authorization decisions without strict validation, and a JWT token claims a role that should only be assigned after strict route-level checks, a request can be split: the proxy may strip or alter headers, but the application parses the remaining headers and JWT payload in a way that elevates privileges.

Consider a scenario where an API endpoint accepts both JSON and form-urlencoded bodies. If the proxy normalizes the request to one format but the AdonisJS app parses another, the Content-Length mismatches can cause one message to be interpreted as two separate requests by the app. When combined with JWT tokens that grant elevated scopes (e.g., scopes that allow modifying sensitive resources), the attacker can smuggle a request that performs an unintended action under authenticated context.

In practice, this maps to common OWASP API Top 10 categories such as Broken Object Level Authorization (BOLA) and can be chained with other weaknesses like improper validation of JWT claims or missing integrity checks on forwarded headers. The risk is not in JWT cryptography itself, but in how the surrounding infrastructure and AdonisJS application interpret and trust metadata derived from proxies and tokens.

To mitigate request smuggling in AdonisJS when using JWT tokens, align header and body parsing with your edge infrastructure, validate all inputs, and avoid trusting potentially malleable metadata. Below are concrete remediation steps and code examples.

1. Enforce strict header validation and avoid relying on mutable forwarded headers

Do not use X-Forwarded-For or similar headers for critical authorization decisions unless you control and validate the entire chain. If you must use them, validate them strictly and treat them as untrusted by default.

// Bad: trusting X-Forwarded-For for authorization
// const forwarded = ctx.request.header('x-forwarded-for');
// if (!forwarded.includes(trustedProxyIp)) { /* deny */ }

// Better: use a strict allowlist of trusted proxies at the infrastructure level
// and do not rely on header values for privilege decisions derived from JWT.

2. Normalize request parsing before JWT verification

Ensure body parsing is consistent regardless of client-supplied hints. Use AdonisJS built-in parsers and avoid switching parsers based on headers that an attacker can control.

// config/bodyparser.ts
import { BodyParserConfig } from '@ioc:Adonis/Core/BodyParser'

const bodyParserConfig: BodyParserConfig = {
  enabled: ['json', 'form-data'],
  jsonLimit: '1mb',
  formLimit: '1mb',
  // Avoid enabling text or custom parsers for authenticated routes unless necessary
}
export default bodyParserConfig

Then in your JWT middleware, verify the token before making authorization decisions based on parsed body content:

// start/hooks.ts or a dedicated middleware
import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'
import { verify } from 'jsonwebtoken'

export default async function authMiddleware(ctx: HttpContextContract, next: () => Promise) {
  const authHeader = ctx.request.header('authorization')
  if (!authHeader?.startsWith('Bearer ')) {
    return ctx.response.unauthorized({ message: 'Unauthorized' })
  }
  const token = authHeader.split(' ')[1]
  try {
    // Use environment variables for secret/key
    const payload = verify(token, processNodeEnv.JWT_SECRET)
    ctx.auth.user = payload as { sub: string; scopes: string[] }
  } catch (error) {
    return ctx.response.unauthorized({ message: 'Invalid token' })
  }
  await next()
}

3. Use strict Content-Type enforcement and body size limits

Configure your server and AdonisJS to reject requests with ambiguous or mismatched Content-Type and Content-Length. This reduces the chance that a proxy and the app interpret the request differently.

// In start/server.ts
import { ServerConfig } from '@ioc:Adonis/Core/Server'

const serverConfig: ServerConfig = {
  allowedMethods: ['GET', 'POST', 'PUT', 'DELETE', 'PATCH'],
  // Reject requests where Content-Type does not match body parser capabilities
  secureJsonPads: true,
}
export default serverConfig

4. Scope JWT claims and validate per-route requirements

Do not rely on JWT scopes or roles alone to authorize actions; enforce route-level checks that are independent of token claims. This prevents a smuggled request with a valid but overprivileged token from succeeding where it shouldn’t.

// Example route-level guard
Route.get('/admin/users', async (ctx) => {
  const user = ctx.auth.user
  if (!user.scopes.includes('admin:users')) {
    return ctx.response.forbidden({ message: 'Insufficient scope' })
  }
  // Proceed with admin logic
})

5. Validate input and avoid ambiguous parsing modes

Be explicit about expected body formats and reject requests that do not match. This prevents a scenario where a proxy normalizes a request to one format while the app parses it as another.

// Example: strictly expect JSON for authenticated endpoints
Route.post('/settings', 'SettingsController.update').middleware(['auth', 'validateJsonBody'])

// resources/validators/validate_json_body.ts
import { schema } from '@ioc:Adonis/Core/Validator'

const schema = {
  body: schema.create({
    contentType: schema.enum(['application/json']),
    // other strict fields
  })
}

export default class ValidateJsonBody {
  public async compile() {
    return schema
  }
}

6. Monitor and test for smuggling indicators

Log suspicious patterns such as repeated Content-Length mismatches or unexpected route interpretations when JWT tokens are present. Use these logs to refine your parsing and validation rules.