Mass Assignment in Feathersjs with Api Keys

Mass Assignment is a well-known OWASP API Top 10 risk where an attacker can set properties they should not be allowed to change. In Feathersjs, services often accept a payload and directly merge it into the data store without explicit allowlisting. When services are protected only by an API Key, the risk is twofold: the key may grant broader permissions than intended, and the service may implicitly trust mass-updatable fields.

Consider a Feathersjs service for updating a user profile. Without proper controls, an API Key that should only allow read access or limited updates can be used to modify sensitive fields such as isAdmin, role, or balance because the service does not strip these keys from the payload:

// Risky service without allowlisting
app.service('users').hooks({
  before: {
    update: [context => {
      // Mass assignment vulnerability: all fields in context.data are applied
      // No filtering of restricted fields like isAdmin
    }]
  }
});

If the endpoint is documented as accepting only email and name, but the code does not enforce this, an attacker who obtains or guesses a valid API Key can craft a request that elevates privileges or manipulates financial data. This becomes a BOLA/IDOR-like issue when the key identifies a user but the service does not verify that the user is only modifying their own allowed fields.

Feathersjs does not implicitly protect against mass assignment; it passes the payload through unless you explicitly remove or validate fields. Relying on API Key authentication alone does not enforce field-level permissions. The combination of weak authorization boundaries (API Key scope) and unrestricted data binding creates a path for privilege escalation or data tampering, which will be reflected in a middleBrick scan as a high-severity finding under Property Authorization and Input Validation.