Ssrf Server Side in Adonisjs with Firestore

Server-side request forgery (SSRF) in an AdonisJS application that interacts with Google Firestore can occur when user-controlled input is used to influence network calls made by server-side code, such as HTTP requests to external endpoints or metadata services. Because AdonisJS is a Node.js framework, server-side logic often includes integrations with external services, and Firestore is commonly accessed via the official Google Cloud client libraries. If an attacker can cause the server to make arbitrary outbound requests—for example, by supplying a malicious URL or metadata endpoint—the server may be forced to reach internal services, cloud metadata (169.254.169.254), or other backends that are not exposed publicly.

In the context of Firestore, SSRF can be triggered when application code uses dynamic inputs to construct Firestore operations or related HTTP calls. For example, if an endpoint accepts a document path or URL and passes it to code that performs Firestore reads or writes, an attacker might supply a path that causes the server to perform metadata queries or reach internal administrative endpoints. Because AdonisJS applications often centralize integrations within providers and controllers, a vulnerable route handler that passes unchecked input into Firestore client methods can expose internal services or bypass intended network boundaries.

An illustrative vulnerable pattern in AdonisJS might involve using a user-supplied hostname or bucket name to initialize a Firestore-related operation or to build a request to Google metadata. Although Firestore client libraries themselves do not typically make arbitrary external HTTP requests based on document data, the surrounding server code might make additional HTTP calls—for example, to validate origins or fetch remote configuration—using the user input. If those calls are not strictly validated, the server can be tricked into SSRF-style behavior, reaching the metadata service or internal endpoints. The risk is compounded when the application runs in cloud environments where the metadata service is reachable from within the runtime.

Because middleBrick scans test the unauthenticated attack surface and include SSRF among the 12 parallel security checks, it can surface such risks when endpoints reflect or forward user-controlled URLs or network destinations. The scanner does not fix the issue but provides findings with remediation guidance, which for AdonisJS with Firestore typically involves strict input allowlists, avoiding forwarding of user input to network calls, and isolating Firestore interactions to trusted, hardcoded configurations.

To mitigate SSRF when using Firestore in AdonisJS, ensure that any user input that could affect network destinations is strictly validated and never used to construct Firestore document paths, HTTP request URLs, or metadata queries. Prefer hardcoded or configuration-based endpoints, and avoid dynamic assembly of external calls based on unchecked parameters.

Example of vulnerable code to avoid:

// ❌ Vulnerable: user-controlled input used to build a document path or URL
const { resourcePath } = request.body()
const fullPath = `projects/myproject/databases/(default)/documents/${resourcePath}`
// Potentially unsafe usage: using user input in network-related operations
const docRef = db.doc(fullPath)
const snapshot = await docRef.get()

Safer approach using strict allowlists and avoiding dynamic URL assembly:

// ✅ Safer: validate input against an allowlist and use hardcoded references
const allowedCollections = ['users', 'products', 'settings']
const { collectionName, documentId } = request.body()

if (!allowedCollections.includes(collectionName)) {
  throw new Error('Invalid collection')
}

// Use trusted, parameterized references instead of string concatenation
const docRef = db.collection(collectionName).doc(documentId)
const snapshot = await docRef.get()

If your application must perform external HTTP calls as part of Firestore workflows, isolate them behind strict validation and avoid forwarding user input:

// ✅ Validate and do not forward raw user input to external endpoints
const { hostname } = request.body()
const allowedHostnames = ['storage.googleapis.com', 'your-internal-config.example.com']
if (!allowedHostnames.includes(hostname)) {
  throw new Error('Invalid hostname')
}
// Use a fixed client with controlled configuration instead of dynamic URLs
const fetch = require('node-fetch')
const response = await fetch(`https://${hostname}/config`, { method: 'GET' })

In AdonisJS, centralize Firestore initialization in a provider or service so that all access follows the same validated patterns. Do not allow route parameters or query strings to dictate Firestore document paths or external destinations. middleBrick’s findings can help identify endpoints where such unsafe patterns exist, and its remediation guidance emphasizes input validation and separation of concerns.