Http Request Smuggling in Feathersjs with Firestore

Http Request Smuggling arises when an API processes HTTP requests in a way that allows an attacker to smuggle a crafted request between two backend interpretations. In a Feathersjs application backed by Cloud Firestore, the risk typically originates from custom service hooks or misconfigured transports rather than Firestore itself, because Firestore is a managed NoSQL database without native HTTP parsing. Feathersjs uses Express under the hood, so if you add raw Express middleware or configure transports (like REST) without consistent parsing, an attacker can exploit differences in how Feathers and the surrounding proxy or load balancer parse requests.

Consider a Feathers service that accepts REST calls and writes to Firestore. If the server is placed behind a reverse proxy or API gateway that buffers requests differently than Feathers’ internal parser, an attacker can craft a request with multiple Content-Length or Transfer-Encoding headers. For example, a request might include a smuggled request in the body after the intended Firestore document create operation. Because Firestore operations are triggered by the service handler and not by direct HTTP routing, the smuggled request can be interpreted as part of the next transaction on the same connection, potentially bypassing intended service boundaries or authentication checks applied at the Feathers service layer.

In practice, this can allow an attacker to perform actions such as reading or modifying documents that should be restricted, by smuggling a request that updates a document the user does not own (a BOLA/IDOR vector). Because Feathers services often rely on hooks for authorization, a smuggled request might skip these hooks if the smuggling causes the request to be parsed in a context where the user context is not properly attached. Firestore rules remain a critical layer, but they do not protect against smuggling that results in the application layer executing unintended operations due to request parsing ambiguity.

An example of a vulnerable Feathers REST setup involves custom middleware that modifies req.headers before the Firestore adapter processes the request. If the middleware does not consistently handle content-length normalization, an attacker can send a request with ambiguous framing:

// Example of a risky custom middleware in a Feathers app using Express
app.use((req, res, next) => {
  // Risky: altering headers without canonicalizing the request
  if (req.headers['x-forwarded-length']) {
    req.headers['content-length'] = req.headers['x-forwarded-length'];
  }
  next();
});

When such a service routes to Firestore via the Feathers Firestore adapter, the smuggling discrepancy can lead to unauthorized document updates or reads. Firestore usage examples in Feathers typically involve a service that calls admin.firestore().collection(...).doc(...).set() or get(), but the vulnerability is in how the HTTP request is interpreted before reaching that code.

To mitigate Http Request Smuggling in a Feathersjs application using Firestore, focus on normalizing HTTP parsing, avoiding header manipulation that can create ambiguity, and ensuring that Feathers services validate authorization on every request regardless of how the request arrives. Do not rely on Firestore security rules alone to prevent smuggling; secure the request pipeline at the Feathers/Express layer.

First, standardize how content-length and transfer-encoding are handled. Remove any custom middleware that selectively overrides headers based on untrusted proxies. Instead, enforce a single source of truth for content-length by letting Express handle it naturally. If you must work with forwarded headers, canonicalize them before they reach Feathers:

// Safer header normalization in a Feathers app
app.use((req, res, next) => {
  const forwarded = req.headers['x-forwarded-length'];
  const original = req.headers['content-length'];
  // Use the original content-length when present; do not overwrite with potentially smuggled values
  if (original !== undefined) {
    req.headers['content-length'] = original;
  } else if (forwarded !== undefined) {
    // Only apply forwarded length when original is absent and you trust the proxy
    req.headers['content-length'] = forwarded;
  }
  next();
});

Second, ensure that each Feathers service method that interacts with Firestore validates ownership and permissions explicitly. Use hooks to attach user context and enforce that a user can only modify their own documents. Here is a Firestore document read example within a Feathers service that includes authorization checks:

const { FirebaseApp } = require('firebase-admin');

// Feathers service hook to validate document ownership before read
async function checkDocumentOwnership(context) {
  const db = FirebaseApp.getInstance().firestore();
  const docRef = db.collection('userData').doc(context.id);
  const doc = await docRef.get();
  if (!doc.exists) {
    throw new Error('Document not found');
  }
  const data = doc.data();
  if (data.userId !== context.params.user.userId) {
    throw new Error('Unauthorized access');
  }
  return context;
}

// Service definition with hook
const userDataService = app.service('user-data');
userDataService.hooks({
  before: {
    get: [checkDocumentOwnership],
    find: [checkDocumentOwnership]
  }
});

Third, avoid mixing transports in a way that creates parsing differences. If you use REST and Socket.io, ensure that the REST layer does not share connection state with the Socket.io layer in a way that could allow cross-protocol smuggling. Keep your Firestore write operations confined to service methods that are invoked after hooks have validated the request.

Finally, test your endpoints with tools that can detect request smuggling, sending ambiguous requests and verifying that responses do not contain unintended data or status codes. Combine this with continuous scanning using a tool that understands Feathersjs and Firestore patterns to detect misconfigurations early.