Mass Assignment in Feathersjs with Jwt Tokens

Mass assignment in a Feathersjs service occurs when a service method such as create or update accepts incoming payload fields and directly maps them to the data model without filtering allowed fields. When JWT tokens are used for authentication, the decoded token payload (e.g., user ID, role, scopes) is commonly merged or combined with the request body, which can unintentionally elevate privileges or expose sensitive writable fields.

Consider a typical Feathersjs authentication setup that attaches a decoded JWT payload to the request object as req.user. A service might then do something like:

app.service('todos').create({ text: 'new task', completed: false, userId: req.user.id, isAdmin: req.user.isAdmin })

If the service does not explicitly whitelist fields, an attacker who can influence any part of the request (for example, via body parameters or query overrides if the framework allows it) may set userId to another user’s ID or set isAdmin to true. Because the JWT token is trusted by the server, the merged object may be accepted as valid, leading to horizontal or vertical privilege escalation (BOLA/IDOR and BFLA/Privilege Escalation). This aligns with OWASP API Top 10 A1: Broken Object Level Authorization and maps to findings such as Property Authorization and Unsafe Consumption in the 12 security checks run by middleBrick.

Moreover, JWT tokens often carry claims that determine access levels (e.g., roles or scopes). If a service uses these claims to make authorization decisions but also permits mass assignment on fields like role or permissions, an attacker can forge a token or tamper with request data to gain elevated capabilities. Even when the JWT is validated and verified, server-side logic that directly assigns request data onto internal objects without schema validation can bypass intended access controls. This is a common root cause for findings related to Property Authorization and BFLA that middleBrick detects through parallel checks including Input Validation and Authorization testing.

The risk is compounded when APIs accept partial updates (PATCH) and merge user-supplied objects with server-derived data from the JWT. Without a strict allowlist, fields such as email, verified, or sensitive application metadata may become writable. middleBrick’s OpenAPI/Swagger analysis (2.0, 3.0, 3.1) with full $ref resolution helps identify which properties are defined in the spec and highlights mismatches between declared schemas and runtime behavior, supporting the detection of such issues.

To remediate mass assignment with JWT tokens in Feathersjs, explicitly define which fields are writable and ensure JWT-derived data is handled separately from user input. Use a controlled merge strategy and validate input against a strict schema before creating or updating records.

Example of insecure code to avoid:

app.service('users').create = async function (data, params) {  return this.Model.create({    ...data,    userId: params.user.id  });};

Instead, use an allowlist and separate authentication data from user-supplied payload:

const allowedUserFields = ['name', 'email', 'timezone'];app.service('users').create = async function (data, params) {  const filteredData = {};  allowedUserFields.forEach(field => {    if (Object.prototype.hasOwnProperty.call(data, field)) {      filteredData[field] = data[field];    }  });  return this.Model.create({    ...filteredData,    userId: params.user.id  });};

For PATCH/UPDATE operations, avoid merging raw payload into the database record. Prefer explicit field assignment or a library that supports schema-based filtering. If using @feathersjs/authentication with JWT, ensure that the JWT payload is used only for authentication context and not directly for authorization fields that can be influenced by the client:

const { authentication } = require('@feathersjs/authentication');const { express } = require('@feathersjs/authentication-express');app.configure(authentication({  secret: process.env.JWT_SECRET,  entity: 'user',  service: 'users',  jwt: {  }  // standard JWT setup}));app.service('todos').create = async function (data, params) {  const allowedFields = ['text', 'dueDate'];  const safeData = {};  allowedFields.forEach(f => { if (data[f] != null) safeData[f] = data[f]; });  return this.Model.create({    ...safeData,    createdBy: params.user.id  });};

Additionally, validate JWT claims server-side before using them in access decisions. Do not rely on client-influenced fields to derive roles or permissions. middleBrick’s LLM/AI Security checks include Active Prompt Injection Testing and System Prompt Leakage Detection, but for API security, rely on schema validation and strict field allowlists to prevent mass assignment regardless of the authentication mechanism.

For ongoing assurance, use the middleBrick Web Dashboard or CLI tool (middlebrick scan <url>) to verify that your endpoints reject unexpected fields and that property authorization checks align with your intended model. The GitHub Action can fail builds if risk scores drop below your chosen threshold, helping prevent regressions that could reintroduce mass assignment issues.