Excessive Data Exposure in Feathersjs with Firestore

Excessive Data Exposure occurs when an API returns more data than necessary for a given operation, such as sensitive fields, internal identifiers, or related records that should remain restricted. In a Feathersjs application using Google Cloud Firestore as the database service, this risk arises from the default behavior of Feathers services and the structure of Firestore documents.

Feathersjs is designed to be framework-agnostic and often relies on generic service methods that return entire database documents. When a Firestore collection is exposed through a Feathers service without explicit field filtering, the full document—including potentially sensitive fields such as internal status flags, administrative metadata, or user identifiers—is returned to the client. This becomes particularly risky when Firestore documents contain nested objects or arrays that are not intended for client-side consumption.

Additionally, Firestore security rules are not enforced by Feathersjs at the application layer. If the service does not explicitly limit the query response, the full result set from Firestore is passed through. An attacker leveraging an unauthenticated or insufficiently authenticated endpoint could trigger a query that returns documents with elevated privileges or sensitive context, especially if the service uses broad query parameters like paginate settings that return large datasets by default.

Common real-world examples include user profile endpoints that inadvertently return password hashes, role flags, or session tokens stored in Firestore fields. In multi-tenant applications, improper scoping of queries can lead to one tenant accessing another tenant’s data through ID manipulation, especially when Firestore document IDs are predictable or sequential. The combination of Feathersjs minimalistic service scaffolding and Firestore’s flexible document structure amplifies the risk if field-level access controls are not explicitly defined.

Another contributing factor is the use of Firestore’s get() or where() queries without projection or field masking. If a Feathers service maps Firestore documents directly to API responses without transformation, sensitive fields such as internalNotes, twoFactorSecret, or auditLog can be exposed. This aligns with the OWASP API Top 10 category A5:2023 – Security Misconfiguration, where excessive data exposure results from overly permissive data retrieval logic.

For regulated environments, such exposures can violate compliance requirements like GDPR or HIPAA if personal data is returned without proper justification or minimization. Continuous scanning with tools that understand both Feathersjs service patterns and Firestore document structures can detect these issues by comparing returned payloads against expected schemas and identifying fields that should be restricted based on context or user role.

To remediate Excessive Data Exposure in Feathersjs with Firestore, implement explicit field selection, query constraints, and response transformation. The goal is to ensure only necessary data is retrieved and returned, and that sensitive fields are never exposed to the client.

1. Use Feathers hooks to transform responses

Feathers hooks allow you to modify the result before it is sent to the client. Use a hook to strip sensitive fields from Firestore documents.

// src/hooks/remove-sensitive.js
module.exports = function removeSensitiveFields() {
  return async context => {
    if (context.result && context.result.data) {
      const { sensitiveField, internalId, ...publicData } = context.result.data;
      context.result.data = publicData;
    }
    return context;
  };
};

Apply this hook to your Firestore service:

// src/services/user-profile/user-profile.hooks.js
const removeSensitiveFields = require('./remove-sensitive');

module.exports = {
  before: { all: [] },
  after: { all: [removeSensitiveFields()] },
  error: { all: [] }
};

2. Project only required fields in Firestore queries

When querying Firestore, use the select method to limit returned fields. This reduces data exposure and improves performance.

// src/services/items/items.service.js
const { Firestore } = require('@google-cloud/firestore');
const firestore = new Firestore();

module.exports = {
  async find(params) {
    const snapshot = await firestore.collection('items')
      .select('name', 'description', 'price')
      .get();

    const items = [];
    snapshot.forEach(doc => {
      items.push({ id: doc.id, ...doc.data() });
    });
    return items;
  }
};

This ensures only name, description, and price are returned, excluding fields like ownerId or internalMetadata.

3. Scoped queries with security-aware parameters

Avoid broad queries. Instead, scope Firestore access to the requesting user and limit the document fields retrieved.

// src/services/orders/orders.service.js
const { Firestore } = require('@google-cloud/firestore');
const firestore = new Firestore();

module.exports = {
  async get(params) {
    const userId = params.user.id;
    const snapshot = await firestore.collection('orders')
      .where('userId', '==', userId)
      .select('orderId', 'total', 'status')
      .limit(10)
      .get();

    return snapshot.docs.map(doc => ({ id: doc.id, ...doc.data() }));
  }
};

This pattern prevents IDOR-related exposure by tying queries to the authenticated user and selecting only necessary fields.

4. Disable automatic population of sensitive fields

If your Firestore documents contain metadata fields used internally, explicitly exclude them in service configuration or via hooks.

// src/services/products/products.hooks.js
module.exports = {
  before: {
    all: [],
    find: [context => {
      // Ensure sensitive fields are not requested
      if (context.params.query && context.params.query.$select) {
        const allowed = ['name', 'sku', 'price'];
        context.params.query.$select = context.params.query.$select
          .split(',')
          .filter(field => allowed.includes(field))
          .join(',');
      }
      return context;
    }]
  },
  after: { all: [] },
  error: { all: [] }
};

These techniques align with best practices for secure API design and help satisfy compliance requirements by enforcing data minimization. When combined with continuous scanning, they reduce the likelihood of sensitive information being unintentionally exposed through Feathersjs services backed by Firestore.