Path Traversal in Adonisjs with Firestore

Path Traversal occurs when an attacker manipulates a file or document identifier to access resources outside the intended directory or collection. In an AdonisJS application that uses Google Cloud Firestore, this typically arises when user-controlled input is used to construct document paths or collection names without strict validation or normalization. Because Firestore addresses resources hierarchically (e.g., users/{userId}/files/{fileId}) or via collection-group queries, insufficient input sanitization can allow an attacker to traverse collections or documents using sequences like ../../ or encoded variants, potentially reaching sensitive documents outside the expected scope.

When AdonisJS directly passes user input into Firestore SDK calls—such as doc(db, 'files', userSuppliedPath)—the path may be interpreted as multiple segments. If the application does not validate that the resulting resource resides within the authorized subtree, the effective access boundary can be bypassed. This risk is compounded when the application uses dynamic collection names or concatenates strings to form document references based on unescaped user data.

Firestore’s rules provide enforcement at runtime, but they are not a substitute for secure server-side handling. A malformed or malicious path can still trigger unintended reads if the server-side code does not canonicalize and validate each path segment. For example, an input like users/attacker%2F..%2Fadmin/settings may resolve to a document under an administrative collection if the server does not normalize the path before passing it to the SDK. Since the scan checks Input Validation and BOLA/IDOR across runtime endpoints, path traversal vectors in this stack are surfaced as actionable findings with severity ratings and remediation guidance.

Moreover, because middleBrick tests unauthenticated attack surfaces, it can detect endpoints that expose Firestore document or collection paths without adequate authorization checks. Findings may reference general access control patterns and map to frameworks such as OWASP API Top 10 (e.g., Broken Object Level Authorization) and highlight the need for strict path validation and principle of least privilege in Firestore security rules.

To mitigate path traversal in AdonisJS when working with Firestore, validate and sanitize all user input before constructing document references. Use explicit allow-lists for identifiers, avoid concatenating raw paths, and enforce hierarchical boundaries in both application logic and Firestore security rules.

1. Validate and normalize path segments

Do not directly use user input as a document ID or path component. Instead, parse and validate each segment to ensure it contains only expected characters and does not contain path traversal sequences.

import { joinPathSegments, doc } from '@google-cloud/firestore';

function sanitizeDocumentId(input) {
  // Allow only alphanumeric, hyphen, and underscore
  if (!/^[a-zA-Z0-9_-]+$/.test(input)) {
    throw new Error('Invalid document ID');
  }
  return input;
}

const userId = sanitizeDocumentId(userInput.userId);
const fileId = sanitizeDocumentId(userInput.fileId);
const fileRef = doc(db, 'users', userId, 'files', fileId);

2. Use Firestore references safely

Construct references using the SDK’s helpers rather than string concatenation. This reduces the risk of unintended path resolution and makes it easier to enforce scope.

import { collection, doc, getDoc } from 'firebase/firestore';

async function getUserData(db, userId, fileId) {
  const safeUserId = sanitizeDocumentId(userId);
  const safeFileId = sanitizeDocumentId(fileId);
  const userDocRef = doc(db, 'users', safeUserId);
  const filesCollection = collection(userDocRef, 'files');
  const fileDocRef = doc(filesCollection, safeFileId);
  const snapshot = await getDoc(fileDocRef);
  return snapshot.exists() ? snapshot.data() : null;
}

3. Enforce boundaries with Firestore rules

Complement server-side validation with security rules that restrict reads and writes to a user’s own data subtree. Avoid wildcards that could inadvertently expose sibling collections or parent paths.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId}/files/{fileId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

4. Avoid dynamic collection names from user input

If your design requires dynamic collections, map user input to a known set of collections rather than using raw input as a collection identifier.

const allowedCollections = ['public', 'archive', 'drafts'];
const collectionName = userInput.collectionName;
if (!allowedCollections.includes(collectionName)) {
  throw new Error('Invalid collection');
}
const colRef = collection(db, collectionName);

By combining strict input validation, safe reference construction, and scoped security rules, you reduce the attack surface for path traversal while preserving the flexibility of Firestore’s hierarchical model.