Request Smuggling in Adonisjs with Mutual Tls

Request smuggling occurs when an intermediary (such as a reverse proxy or load balancer) processes HTTP requests differently than the origin server. In AdonisJS applications that terminate Mutual TLS (mTLS), the combination of strict client certificate validation at the edge and framework-level parsing of request streams can create conditions where smuggling becomes possible. mTLS requires the server to validate the client certificate before the application layer inspects the request. AdonisJS, like many Node frameworks, buffers and parses HTTP messages after the TLS layer is established. When the front-end terminates mTLS and forwards the request to AdonisJS over an unencrypted or differently configured channel, discrepancies in how headers are buffered and parsed can emerge.

One specific scenario involves inconsistent handling of Content-Length and Transfer-Encoding headers between the mTLS terminator and AdonisJS. If the terminator processes and removes certain hop-by-hop headers but AdonisJS still sees a smuggled request sequence (for example, a request with both Content-Length and Transfer-Encoding, or multiple requests concatenated in a single TCP stream), the framework may parse the second request as part of the first. This can lead to BOLA/IDOR-like effects where one client’s body is processed as another’s, or where request routing is manipulated. Because mTLS enforces client identity early, developers may assume the transport is fully trusted and inadvertently relax parsing safeguards at the application layer, which increases the risk of smuggling exploits.

During a middleBrick scan of an AdonisJS endpoint with mTLS enabled, checks such as Input Validation, BOLA/IDOR, and Unsafe Consumption are exercised against the live endpoint. The scanner can detect whether header parsing allows ambiguous message boundaries and whether the application treats forwarded requests as originating from the mTLS client. Findings often highlight missing normalization of headers like X-Forwarded-Proto and the absence of strict message framing, which are critical when mTLS terminates upstream. Remediation focuses on ensuring the framework enforces consistent parsing regardless of transport termination points and that the application does not implicitly trust hop-by-hop headers that should be removed by intermediaries.

To mitigate request smuggling in AdonisJS with mTLS, align header parsing and transport handling so the application does not rely on potentially inconsistent forwarding behavior. Explicitly normalize and remove hop-by-hop headers within AdonisJS middleware before routing or body parsing. Enforce strict Content-Length and Transfer-Encoding handling so that only one message framing mechanism is active per request. When mTLS is handled upstream, ensure the endpoint validates the presence and integrity of the original client certificate via configured headers only when they are explicitly trusted and verified.

Below are concrete AdonisJS code examples that demonstrate mTLS-aware middleware and request handling. These examples do not enable or disable mTLS at the transport layer (that is done at the proxy or server configuration) but show how AdonisJS can safely process requests that arrive with mTLS-derived metadata.

// start/hooks.ts
import { IHookContext } from '@adonisjs/core/types'

export const handleMtlsHeaders = (ctx: IHookContext) => {
  const request = ctx.request
  // Only use forwarded headers if you terminate TLS upstream and explicitly trust the chain
  const xForwardedCert = request.header('x-forwarded-client-cert')
  if (xForwardedCert) {
    // Validate the certificate fingerprint or issuer against an allowlist
    const fingerprint = request.fingerprint(xForwardedCert)
    const allowedFingerprints = new Set([process.env.ALLOWED_CERT_FP_1, process.env.ALLOWED_CERT_FP_2])
    if (!allowedFingerprints.has(fingerprint)) {
      throw request.abort(403, 'invalid-client-certificate')
    }
  }
}

// middleware/mtls_validation.ts
import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'

export default class MtlsValidationMiddleware {
  public async handle(ctx: HttpContextContract, next: () => Promise) {
    // Ensure message framing is unambiguous before parsing the body
    const hasContentLength = ctx.request.has('content-length')
    const hasTransferEncoding = ctx.request.header('transfer-encoding')?.toLowerCase()

    if (hasContentLength && hasTransferEncoding) {
      // Reject requests with both headers to prevent smuggling
      ctx.response.status(400).send({ error: 'conflicting-framing-headers' })
      return
    }

    // Normalize hop-by-hop headers that should not be forwarded
    ctx.request.removeHeader('keep-alive')
    ctx.request.removeHeader('proxy-authenticate')
    ctx.request.removeHeader('proxy-authorization')
    ctx.request.removeHeader('te')
    ctx.request.removeHeader('trailers')
    ctx.request.removeHeader('transfer-encoding')

    await next()
  }
}

// Example route usage with middleware
Route.post('/secure-endpoint', [handleMtlsHeaders, MtlsValidationMiddleware.handle], async ({ request }) => {
  const body = request.body()
  return { received: body, clientFingerprint: request.fingerprint(request.header('x-forwarded-client-cert') || '') }
})

These patterns ensure that AdonisJS evaluates request boundaries consistently, reducing the risk that a smuggled request slips through due to framework or middleware assumptions. When using the middleBrick CLI (middlebrick scan <url>) or GitHub Action to integrate API security checks into your CI/CD pipeline, you can validate that such mitigations are reflected in runtime behavior and that headers are handled securely across the mTLS boundary.