Nosql Injection in Adonisjs with Jwt Tokens

AdonisJS is a Node.js web framework that often uses JSON Web Tokens (JWT) for stateless authentication. When JWT handling and NoSQL-like data stores (e.g., MongoDB, JSON-based APIs, or in-memory object stores) are combined without strict validation, patterns that appear safe can still introduce injection-like risks. A JWT typically carries a payload that an application may treat as untrusted input when querying a database or filtering records. If the server deserializes the token and directly uses claims such as sub or roles in a query without validation, an attacker can influence behavior through token manipulation or injection via application logic that interprets user-controlled data as query syntax.

Consider an endpoint that identifies a user by ID extracted from a JWT and retrieves a profile document. If the application uses the decoded token value to construct a filter object for a NoSQL query, unsanitized or loosely typed data can change the query semantics. For example, using a numeric ID from the token in a MongoDB query without type validation can allow an attacker to supply values that alter the query structure, such as injecting operators that change matching behavior. This is not a classic SQL injection, but it mirrors injection logic: untrusted data affects how a query is interpreted. In AdonisJS, routes and controllers may directly use request parameters or token claims to build queries, increasing risk if input is not normalized and validated.

Another scenario involves role-based access control encoded in a JWT. If the server places token claims into query filters, such as { owner: decoded.role } without strict schema checks, an attacker who can influence the token (via weak signing algorithms, stolen tokens, or application bugs) may escalate privileges or access other users’ data. Even when tokens are cryptographically signed, the application must treat all claims as untrusted input. AdonisJS middleware can verify signatures, but developers must still sanitize and validate data before it reaches the persistence layer. Misconfigured middlewares or inconsistent validation across routes can leave a gap where a token-derived value is trusted implicitly, enabling injection-like behavior against NoSQL stores.

JWT tokens can also carry complex nested objects. If an application merges token payloads into query objects without deep validation, nested fields may introduce unexpected operators or paths. For instance, merging a decoded object into a query filter can inadvertently expose fields that should be server-side only, or allow injection of operators like $in or $exists when the application expects simple equality checks. This becomes a server-side request forgery or data exposure vector when combined with weak type checks. Therefore, the combination of JWT tokens and NoSQL-style queries demands rigorous input validation, strict schema enforcement, and separation of trusted metadata from user-controlled data.

To mitigate risks when using JWT tokens in AdonisJS, enforce strict validation and avoid direct use of token claims in queries. Always verify the token signature, validate claims, and map them to a controlled data model before using them in database operations. Below are concrete, syntactically correct examples that demonstrate secure patterns.

First, configure JWT authentication in AdonisJS and ensure tokens are verified with strong algorithms. Use environment-based secret keys and avoid weak signing methods. Then sanitize and validate claims before building query filters.

import { BaseMiddleware } from '@ioc:Adonis/Core/Middleware'
import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'
import { schema, rules } from '@ioc:Adonis/Core/Validator'
import { authenticator } from '@ioc:Adonis/Addons/Auth'

export default class JwtValidationMiddleware extends BaseMiddleware {
  public async handle({ request, auth }, next) {
    const token = request.header('authorization')?.replace('Bearer ', '')
    if (!token) {
      return response.unauthorized('Missing token')
    }

    try {
      const payload = await authenticator.verify(token, { expiresIn: '1h' })
      request.authUser = payload
      await next()
    } catch (error) {
      return response.unauthorized('Invalid token')
    }
  }
}

Second, validate claims with a strict schema before using them in query construction. Do not trust raw token payloads. Define a validator that enforces types and allowed values.

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

const userFilterSchema = schema.create({
  userId: schema.number([rules.range(1, 999999999)]),
  role: schema.enum(['user', 'admin'] as const),
})

export async function validateUserFilter(data: any) {
  return schema.validate({ schema: userFilterSchema, data })
}

Third, build query filters using validated, normalized values instead of raw token claims. For MongoDB-like operations in AdonisJS (e.g., with Lucid or custom providers), use parameterized inputs and avoid injecting token-derived objects directly into query builders.

import { User } from 'App/Models/User'
import { validateUserFilter } from 'App/Validators/user'

export class UserController {
  public async show({ request, response }) {
    const tokenClaims = request.authUser
    const validated = await validateUserFilter({
      userId: tokenClaims.sub,
      role: tokenClaims.role,
    })

    // Safe query construction using validated scalar values
    const user = await User.query()
      .where('id', validated.userId)
      .preload('profile')
      .firstOrFail()

    return response.ok(user)
  }
}

Finally, enforce role-based access at the route or policy level rather than embedding permissions directly in token payloads used for query filters. This reduces the attack surface if token data is ever mishandled or misinterpreted. Combine middleware checks with schema validation to ensure that every NoSQL query uses only sanitized inputs.