Type Confusion in Adonisjs with Jwt Tokens

Type confusion in AdonisJS when handling JSON Web Tokens (JWT) arises when a value expected to be a specific type is mistakenly treated as another type, bypassing intended validation or access controls. This typically occurs when string-based token payload claims are used in a numeric or boolean context without explicit conversion, or when dynamic payload deserialization does not enforce strict schemas.

In AdonisJS, JWTs are commonly issued and verified using the jwt utility from @adonisjs/auth. If a claim such as userId is stored as a string in the token payload but later compared directly to a numeric database ID without coercion, an attacker may exploit loose equality (==) or improper casting to escalate privileges. For example, an attacker could manipulate their token payload to set userId: "0" or userId: "1" and, if the application uses non-strict checks, gain access to another user’s resources via IDOR (Insecure Direct Object References).

Another scenario involves role-based access where a claim like role is expected to be a string but is interpreted as an object or number due to inconsistent deserialization. If the application checks if (role === 'admin') but role is actually a number (e.g., 1) because of a misconfigured serializer or a maliciously crafted token, the condition may evaluate unexpectedly, potentially granting elevated permissions.

AdonisJS applications that use signed but not strictly validated JWTs are also exposed if they propagate payload values into contexts that rely on type-sensitive operations, such as array indexing or switch statements. An attacker could supply an array where a scalar is expected, leading to runtime coercion that bypasses intended logic. This becomes critical when the token influences authorization decisions, such as determining scope or tenant isolation.

Because middleBrick scans test unauthenticated attack surfaces and include JWT-related checks within its 12 security checks, it can detect indicators of type confusion in API responses that reflect malformed or weakly validated tokens. Findings may highlight missing schema enforcement, improper claim handling, or unsafe deserialization patterns that could be leveraged for privilege escalation or BOLA/IDOR.

To detect these issues during development, developers should validate payload types explicitly and avoid relying on implicit coercion. middleBrick’s OpenAPI/Swagger analysis, which supports full $ref resolution, can help identify inconsistencies between declared schemas and runtime behavior when an OpenAPI spec is available.

Remediation centers on strict type validation, schema enforcement, and avoiding implicit type conversions when processing JWT payloads in AdonisJS. Always treat claims as untrusted and enforce types before use.

1. Use strict equality and explicit type conversion

Ensure numeric IDs are parsed and compared using strict checks. Do not rely on loose equality.

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

export default class UserMiddleware implements BaseMiddleware {
  public async handle({ auth, params }: HttpContextContract, next: () => Promise) {
    const requestedId = parseInt(params.id, 10)
    if (Number.isNaN(requestedId)) {
      throw new Error('Invalid user ID')
    }
    const user = await auth.authenticate()
    if (user.id !== requestedId) {  // strict equality
      throw new Error('Unauthorized')
    }
    await next()
  }
}

2. Validate JWT payload claims with a schema

Use a runtime validation library to enforce types for decoded tokens. This prevents type confusion from malformed or malicious payloads.

import { schema, rules } from '@ioc:Adonis/Core/Validator'
import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'
import { verify } from 'jsonwebtoken'

const tokenSchema = schema.create({
  sub: schema.string({}, [rules.uuid()]),
  role: schema.string({}, [rules.oneOf(['user', 'admin'])]),
  exp: schema.number()
})

export function validateToken(token: string) {
  const decoded = verify(token, process.env.JWT_SECRET!)
  return tokenSchema.validate(decoded)
}

3. Enforce role checks with type-safe comparisons

Do not compare roles using non-strict equality or numeric casts.

const userRole = String(payload.role)
if (userRole !== 'admin') {
  throw new Error('Forbidden')
}

4. Use typed access to token claims

When using the auth module, prefer typed accessors and avoid direct manipulation of payload values that may change type.

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

export function requireAdmin(ctx: HttpContextContract) {
  const user = ctx.auth.user
  if (!user || user.role !== 'admin') {
    throw new Error('Admin access required')
  }
}

middleBrick’s CLI tool (middlebrick scan <url>) can surface weak JWT validation practices by analyzing runtime behavior and spec definitions. For continuous protection, the Pro plan’s GitHub Action can fail builds when insecure token handling patterns are detected, integrating API security checks into CI/CD pipelines. The MCP Server allows AI coding assistants to surface these issues during development, helping maintain strict type handling for JWTs in AdonisJS applications.