HIGH mass assignmentadonisjsjwt tokens

Mass Assignment in Adonisjs with Jwt Tokens

Mass Assignment in Adonisjs with Jwt Tokens — how this specific combination creates or exposes the vulnerability

Mass assignment in AdonisJS occurs when an API endpoint binds incoming request fields directly to a model or its related database record without an allowlist. When JWT tokens are used for authentication, the token payload often carries user metadata (e.g., role, isAdmin, permissions) that may be inadvertently bound to request bodies or query parameters. If the application merges token-derived claims into request body parsing and then performs mass assignment, an attacker can supply unexpected keys that override privileged fields such as role, isAdmin, or tenantId. This combination—permissive model binding plus token-derived data—creates an authorization bypass where a standard user can escalate privileges or manipulate ownership checks.

Consider an endpoint that updates a user profile and also accepts a role claim from the JWT. If the route handler does not filter fields and uses the model’s merge or create methods on the parsed body, an attacker can add a role key to the payload and change their own role. The JWT signature verifies identity but does not enforce authorization boundaries; the server must still validate which fields are writable. Without an explicit allowlist, mass assignment can modify sensitive columns such as isVerified, tenantId, or even impersonate another user by setting userId in the payload. AdonisJS’s Lucid models provide merge and create methods that, when used naively, propagate all provided keys into the database, making the framework a common vector for this vulnerability in token-based systems.

In practice, this vulnerability surfaces when authentication middleware attaches decoded JWT claims to the request context and the route handler passes request body plus claims into a mass assignment operation. For example, merging req.body with req.auth.claims and then calling User.query().merge(payload).update() can overwrite immutable fields. The risk is higher in admin or multi-tenant scenarios where token claims include roles or scopes that should never be user-controlled. Attack patterns include role elevation, tenant hopping, and unauthorized data access. Proper remediation requires strict input validation, an explicit allowlist for mass assignment, and scoping queries to the authenticated subject rather than trusting token claims for authorization decisions.

Jwt Tokens-Specific Remediation in Adonisjs — concrete code fixes

To secure mass assignment when JWT tokens are used, apply an explicit allowlist, avoid merging raw request bodies directly into models, and keep authorization claims separate from mutatable fields. Below are concrete, syntactically correct examples for AdonisJS using the @adonisjs/auth package and JWT utilities.

import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'
import User from 'App/Models/User'
import { schema, rules } from '@ioc:Adonis/Core/Validator'

// Define an allowlist that excludes sensitive or token-derived fields
const updateProfileSchema = schema.create({
  firstName: schema.string.optional(),
  lastName: schema.string.optional(),
  email: schema.string.optional([rules.email()]),
  // Never include role, isAdmin, or tenantId in the allowlist for user updates
})

export default class UsersController {
  public async updateProfile({ request, auth, response }: HttpContextContract) {
    const user = auth.user
    if (!user) {
      return response.unauthorized()
    }

    // Validate only safe, user-controlled fields
    const payload = await request.validate({ schema: updateProfileSchema })

    // Explicitly merge only allowed fields; do not merge token claims
    await user.merge(payload).save()

    return user
  }
}

In this example, the validator ensures only permitted fields are accepted, preventing role or admin escalation via mass assignment. The handler uses auth.user directly rather than merging JWT claims into the update payload.

When you need to incorporate token metadata for logging or contextual operations, keep it separate from mass assignment:

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

const safeUpdateSchema = schema.create({
  username: schema.string(),
  bio: schema.string.optional(),
})

export async function updateWithClaims(ctx: HttpContextContract) {
  const user = ctx.auth.user
  const body = await ctx.request.validate({ schema: safeUpdateSchema })

  // Use claims for read-only decisions, not for merging into mutable fields
  const roleClaim = ctx.auth.token.payload.get('role')
  // Log or apply business logic based on roleClaim, but do not assign it to user
  if (roleClaim === 'admin') {
    // perform admin-specific logic without mutating user.role via mass assignment
  }

  await user.merge(body).save()
  return user
}

Additionally, avoid merging the entire request body with token-derived claims. If your API must accept dynamic fields, validate and pick only known safe keys instead of using model.merge(request.all()) which is prone to mass assignment. For authorization, enforce row-level policies and scope queries by the authenticated user ID rather than trusting token claims to determine permissions.

Finally, configure JWT signing and verification securely, and do not embed mutable authorization data in the token payload that the server might mistakenly use to update records. Combine schema validation, explicit field selection, and query scoping to prevent mass assignment across authenticated endpoints.

Related CWEs: propertyAuthorization

CWE IDNameSeverity
CWE-915Mass Assignment HIGH

Frequently Asked Questions

Can mass assignment happen even if JWT tokens are signed and verified?
Yes. Signature verification confirms token integrity and identity, but it does not enforce authorization. If your handler merges token claims or request body into a model without an allowlist, mass assignment can still modify sensitive fields.
Does using JWT tokens with roles eliminate the need for an allowlist in mass assignment?
No. Roles in tokens identify the subject but should not be used to decide mutatable fields. Always use a strict allowlist and scope updates to the authenticated user ID; never trust token-derived fields for authorization or mass assignment.