Path Traversal in Loopback with Firestore

A path traversal risk arises in a Loopback application that uses Firestore when user-controlled input is used to construct document paths, references, or collection/ID values without strict validation or normalization. For example, if an endpoint accepts a documentId or a Firestore document path from the client and directly passes it to Firestore APIs (such as doc(db, "users", userId)), an attacker can supply sequences like ../../../admin/roles/123 or encoded variants to escape the intended resource scope.

Firestore itself does not allow .. in document IDs, but a Loopback controller that builds a document reference from concatenated or interpolated user input can point to an unintended parent collection or document. Consider a route intended to fetch a user profile:

const userId = req.query.userId; // attacker-controlled
const userRef = doc(db, 'users', userId);
const snapshot = await getDoc(userRef);

If userId is ../../config/settings, the resulting logical path may resolve outside the intended collection depending on how the application normalizes or uses the value elsewhere (e.g., in logging, secondary lookups, or constructing further references). Even when Firestore rejects the write, information leakage can occur via error messages that reveal collection structure or existence of parent documents.

Another scenario involves file-like access through exported data where document IDs or paths are reflected in responses or used to build storage keys. An attacker probing IDs such as ../../../serviceAccountKey may learn whether broader access patterns exist. The risk is compounded when combined with insufficient authorization checks (BOLA/IDOR), where a missing ownership or role validation allows traversal across tenant or privilege boundaries.

Because middleBrick scans the unauthenticated attack surface and tests endpoints such as GET /users?userId=..%2F..%2Fadmin, it can surface these path traversal risks by observing whether responses differ across traversal attempts and whether sensitive data or structural differences are returned. Findings include the specific endpoint, parameter, and evidence of unintended document resolution, mapped to relevant portions of the OWASP API Top 10 and compliance frameworks.

To mitigate path traversal in Loopback with Firestore, enforce strict validation and canonicalization of any user input used to build document references. Use allowlists for document IDs (alphanumeric plus safe separators) and avoid string concatenation to form paths. Prefer Firestore’s built-in APIs to reference documents safely.

Instead of directly interpolating user input, parse and validate the input, then use Firestore’s doc and collection helpers with fixed base paths. For example, to fetch a user profile safely:

const { documentId } = req.query;
// Allowlist validation: only alphanumeric and underscores
if (!/^[a-zA-Z0-9_]+$/.test(documentId)) {
  throw new Error('Invalid document ID');
}
const userRef = doc(db, 'users', documentId);
const snapshot = await getDoc(userRef);
if (!snapshot.exists()) {
  throw new Error('Not found');
}

When you need hierarchical scoping (e.g., tenant-aware data), encode the tenant as a fixed collection and treat the remainder as a validated document ID:

const tenant = 'acme'; // from a trusted source, not user input
if (!/^[a-zA-Z0-9_-]+$/.test(tenant)) {
  throw new Error('Invalid tenant');
}
const userId = 'u_12345'; // validated separately
const userRef = doc(db, 'tenants', tenant, 'users', userId);
const snapshot = await getDoc(userRef);

For endpoints that accept full paths for administrative operations, normalize the path using Firestore utilities and ensure the resolved path is within an allowed subtree. Reject any path containing encoded traversal sequences or that resolves outside the permitted scope. Combine this with robust authorization checks (BOLA/IDOR) so that even if an ID is valid, the requesting subject must own or be permitted to access that resource.

Leverage middleBrick’s scans (via the CLI with middlebrick scan <url>, the Web Dashboard, or the GitHub Action) to validate that your endpoints do not reflect traversal attempts and that findings align with remediation guidance. The LLM/AI Security checks can further confirm whether error messages or responses inadvertently disclose collection structures.