Excessive Data Exposure in Feathersjs with Mongodb

Excessive Data Exposure occurs when an API returns more data than the client needs, often including sensitive fields or entire database documents. With Feathersjs and MongoDB, this risk arises from default service configurations and query handling that do not explicitly limit returned fields. Feathersjs services, by design, map operations to MongoDB collections and can return full documents unless projection or filtering is applied. If a service does not specify which fields to include or exclude, MongoDB returns the complete document, potentially exposing fields such as passwords, tokens, internal identifiers, or personal information.

In Feathersjs, service methods like find and get accept a params object that can include query properties such as query and paginate. Without explicit field selection, these methods pass queries directly to the MongoDB driver. The MongoDB driver, when no projection is provided, returns all fields stored in the matching documents. This behavior can inadvertently expose sensitive data in unauthenticated or improperly scoped endpoints, especially when combined with REST or socket transport layers that expose results to a broad audience.

Consider an example where a Feathersjs service for user profiles does not limit returned fields. A request to /users might return the full user document, including fields such as password, salt, verificationToken, or internal metadata. If the client application renders this data in a frontend without additional validation, sensitive information may be exposed in browser developer tools or logs. Attackers can leverage unauthenticated endpoints or compromised client-side code to harvest these fields, leading to account takeover or privacy violations.

Another scenario involves nested or populated references. Feathersjs services can be extended with hooks or custom logic that populate related collections. Without careful configuration, these operations may return entire related documents, exposing additional sensitive contexts. For instance, populating a role collection might reveal administrative flags or permission scopes that should not be visible to non-privileged clients. This chaining of data exposure across collections increases the attack surface and can violate data minimization principles defined in regulations such as GDPR.

Real-world attack patterns mirror these risks. The OWASP API Security Top 10 category A01:2023 Broken Object Level Authorization often intersects with Excessive Data Exposure when combined field leakage occurs. Specific CVEs in related ecosystems, such as those involving unauthenticated endpoints returning full user objects, demonstrate the practical impact. In MongoDB, fields stored in flexible schemas may retain deprecated or sensitive keys that are no longer actively managed, increasing the likelihood of unintentional exposure through legacy service routes.

To mitigate these risks within Feathersjs and MongoDB, developers must explicitly define field selection using projection in service hooks or query parameters. This requires understanding how Feathersjs translates service calls into MongoDB operations and ensuring that projection rules are applied consistently across find, get, and custom methods. Security-focused code reviews should verify that no service returns full documents by default and that sensitive fields are excluded based on role and context.

Remediation focuses on enforcing field-level filtering in MongoDB queries initiated by Feathersjs services. The most direct approach is to use projection within query objects to include only necessary fields. In MongoDB, projection specifies which fields to include or exclude using boolean flags, where 1 indicates inclusion and 0 indicates exclusion. Feathersjs allows passing these projection rules through the query object in service method calls or within hooks that modify parameters before database interaction.

For example, to retrieve only non-sensitive fields for a user query, define a find method call with a projection that excludes password hashes and tokens:

// In a Feathersjs service handler or hook
app.service('users').find({
  query: {
    $select: ['id', 'email', 'firstName', 'lastName', 'role'],
    isActive: true
  }
});

Internally, the MongoDB driver translates $select into a projection document such as { id: 1, email: 1, firstName: 1, lastName: 1, role: 1 }, ensuring that only specified fields are returned. This prevents leakage of fields like password or verificationToken that may exist in the collection schema.

For the get method, which retrieves a single document by ID, apply projection directly in the parameters object:

app.service('users').get('12345', {
  query: {
    $select: ['id', 'email', 'username']
  }
});

In hooks, modify the params.query object to inject projection rules based on authentication context. For instance, an after hook can restrict sensitive fields for non-admin roles:

app.hooks({
  after: {
    all: [],
    find: [context => {
      if (!context.params.user || !context.params.user.isAdmin) {
        context.params.query.$select = context.params.query.$select || [];
        // Ensure sensitive fields are excluded
        const sensitiveFields = ['password', 'salt', 'verificationToken'];
        sensitiveFields.forEach(field => {
          context.params.query.$select[field] = 0;
        });
      }
      return context;
    }]
  }
});

When using population or related data retrieval, explicitly define which fields from related collections should be projected. This prevents over-fetching across references and limits exposure of interconnected sensitive data:

app.service('posts').find({
  query: {
    $select: ['title', 'content', 'authorId'],
    authorId: {
      $select: ['id', 'username', 'email']
    }
  }
});

Combining these techniques ensures that Feathersjs services interacting with MongoDB adhere to the principle of least privilege regarding data exposure. Regular audits of service definitions and hook logic help maintain consistent field-level control across the API surface.