Identification Failures in Feathersjs (Javascript)

FeathersJS is a JavaScript framework for real-time APIs. When identification logic is implemented incorrectly in FeathersJS services using plain JavaScript, it can lead to Identification Failures, allowing one user to act as another by manipulating identifiers such as user IDs or tokens. Because FeathersJS services commonly rely on params.user and custom id fields, omitting strict ownership checks on these values enables Insecure Direct Object References (IDOR) and Broken Object Level Authorization (BOLA).

In a FeathersJS service written in JavaScript, the framework does not automatically enforce that a requesting user can only access their own records. For example, a users service might expose a GET endpoint like /users/123 where the ID is taken directly from the request without verifying that the authenticated user corresponds to ID 123. If the service uses JavaScript code that does not compare params.user.user_id with the requested resource identifier, an attacker can change the ID in the URL to enumerate other accounts.

Identification Failures often arise when using query parameters to filter records without scoping to the authenticated user. Consider a FeathersJS service that retrieves messages using a JavaScript handler that applies a filter on userId only when provided. An attacker supplying a different userId in the query can read messages belonging to other users if the service does not override the filter with the authenticated user's ID.

Real-world examples align with common attack patterns such as IDOR (CWE-639) and BOLA. These vulnerabilities are frequently found in APIs that expose numeric or UUID identifiers without scoping. The absence of per-request authorization that ties the subject to the object identifier is a root cause. middleBrick’s checks for BOLA/IDOR, Property Authorization, and Unsafe Consumption highlight these risks by correlating unauthenticated and authenticated runtime behavior with the OpenAPI spec definitions and JavaScript route handlers.

Additionally, identification mechanisms that rely solely on client-supplied identifiers without server-side reconciliation are vulnerable. For instance, using a URL path parameter as the sole source of truth in JavaScript service code, without cross-checking it against the authenticated subject stored in params.user, creates a weak link. This is especially critical when the API also supports legacy or custom authentication schemes where tokens may be misinterpreted.

Because middleBrick scans the unauthenticated attack surface and runs checks in parallel, it can detect endpoints where identification controls are missing or misconfigured in FeathersJS JavaScript services. The tool cross-references the OpenAPI/Swagger spec (including $ref resolution) with runtime behavior, flagging inconsistencies such as exposed identifiers and missing user scoping that could lead to unauthorized data access.

To remediate Identification Failures in FeathersJS using JavaScript, explicitly scope data access to the authenticated user and validate identifiers on every request. Use params.user to enforce ownership and avoid trusting client-supplied IDs without verification.

Example vulnerable code

// @filename: src/services/messages/messages.js
const { Service } = require('feathersjs');

class MessageService extends Service {
  async find(params) {
    const { userId } = params.query;
    // Vulnerable: userId from query is used without ownership check
    return this.select('app').Model.findAll({ where: { userId } });
  }

  async get(id, params) {
    // Vulnerable: id from URL is used directly
    return this.select('app').Model.findByPk(id);
  }
}

module.exports = function (app) {
  app.use('/messages', new MessageService({ Model: app.get('MessageModel') }));
};

Remediated code example

// @filename: src/services/messages/messages.js
const { Service } = require('feathersjs');

class MessageService extends Service {
  async find(params) {
    // Ensure the query is scoped to the authenticated user
    const userId = params.user && params.user.user_id;
    if (!userId) {
      throw new Error('Unauthorized');
    }
    // Override any incoming query.userId with the authenticated user's ID
    const query = { ...params.query, userId };
    // Remove internal userId from query to avoid accidental filtering issues
    delete query.userId;
    return this.select('app').Model.findAll({ where: query });
  }

  async get(id, params) {
    const userId = params.user && params.user.user_id;
    if (!userId) {
      throw new Error('Unauthorized');
    }
    const record = await this.select('app').Model.findByPk(id);
    // Enforce ownership: ensure the record belongs to the authenticated user
    if (!record || record.userId !== userId) {
      throw new Error('Not found');
    }
    return record;
  }
}

module.exports = function (app) {
  app.use('/messages', new MessageService({ Model: app.get('MessageModel') }));
};

Remediation best practices

• Always derive the user identifier from params.user rather than from query parameters or path variables.
• In find, merge the authenticated user ID into the query filter and remove any user-supplied userId to prevent override.
• In get, after fetching the record by ID, compare the record’s owning user field with params.user.user_id and reject access on mismatch.
• For services that support additional filters, ensure that ownership scoping is applied before any $select or ORM operations.
• Apply consistent authorization across all methods (create, update, patch, remove) by using hooks that validate params.user and object ownership.

These JavaScript-specific fixes reduce the risk of Identification Failures by ensuring that every data access operation is bound to the authenticated subject. When combined with middleBrick’s continuous monitoring and CI/CD integration in the Pro plan, regressions in identification controls can be caught before deployment.