Xpath Injection in Echo Go with Firestore

XPath Injection occurs when an attacker can influence an XPath expression constructed from untrusted data. In an Echo Go service that uses Firestore, this typically happens if the application builds XPath-like queries (for example when using a Firestore-like abstraction or custom XML/JSON path handling) by concatenating user input directly into the expression string. Because Firestore itself does not use XPath, the exposure arises not from Firestore’s native API but from how the Go application processes data before it reaches Firestore or when using auxiliary libraries that interpret paths as expressions.

Consider an endpoint that retrieves a user document by a path derived from URL parameters:

// Unsafe: concatenating user input into a Firestore document path or XPath-like selector
docPath := c.Param("collection") + "/" + c.Param("documentID")
var result map[string]interface{}
if err := db.Collection(docPath).Doc("data").Get(ctx, &result); err != nil {
    c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
    return
}
c.JSON(http.StatusOK, result)

If collection or documentID are attacker-controlled, an adversary can inject path traversal or selector logic (e.g., users/../../../secrets). Even when Firestore enforces security rules, malformed or malicious paths can bypass intended access controls if the server-side validation is weak. In scenarios where XPath is used separately (e.g., parsing exported XML data stored in Firestore), unsanitized input fed to an XPath evaluator can yield similar injection outcomes, such as unauthorized document traversal or data extraction.

An attacker might supply a crafted parameter like ?collection=users&documentID=admin' or '1'='1 to manipulate logical conditions in custom XPath logic, or exploit path traversal sequences to reach parent-level collections. Because the scan is unauthenticated, middleBrick tests these endpoints by submitting such payloads and inspecting responses for anomalies like missing data, server errors, or unintended data disclosure, which indicate insufficient input validation and improper path handling.

Remediation guidance centers on strict input validation, avoiding concatenation for path construction, and using parameterized approaches. Never trust client-supplied identifiers for collection or document names. Apply allowlists for expected values and enforce strict schema checks before any Firestore operation.

Securely interacting with Firestore in Echo Go requires avoiding dynamic path assembly and ensuring all inputs are validated and sanitized. Use fixed paths or map user input to known document IDs through a lookup rather than string concatenation. Below are concrete, safe patterns.

1. Validate and map inputs before Firestore operations

Define a set of allowed collections and resolve document identifiers through a controlled mapping or lookup. This prevents path traversal and injection attempts.

// Safe: using a predefined allowlist for collections
var allowedCollections = map[string]bool{
    "users": true,
    "posts": true,
}

func getDocument(c echo.Context) error {
    collection := c.Param("collection")
    docID := c.Param("documentID")

    if !allowedCollections[collection] {
        return c.JSON(http.StatusBadRequest, gin.H{"error": "invalid collection"})
    }
    if docID == "" || strings.ContainsAny(docID, " /\\#?[]") {
        return c.JSON(http.StatusBadRequest, gin.H{"error": "invalid document ID"})
    }

    ref := db.Collection(collection).Doc(docID)
    ctx := c.Request().Context()
    snap, err := ref.Get(ctx)
    if err != nil {
        return c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to fetch document"})
    }
    if !snap.Exists() {
        return c.JSON(http.StatusNotFound, gin.H{"error": "document not found"})
    }
    return c.JSON(http.StatusOK, snap.Data())
}

2. Use Firestore queries with structured parameters

Instead of building paths from raw input, use Firestore’s query mechanisms with explicit filters. This ensures that queries are parameterized and safe from injection.

// Safe: parameterized query using Firestore client
func queryUser(c echo.Context) error {
    userID := c.Param("userID")
    if userID == "" {
        return c.JSON(http.StatusBadRequest, gin.H{"error": "userID is required"})
    }

    iter := db.Collection("users").Where("uid", "==", userID).Limit(1).Documents(c.Request().Context())
    defer iter.Stop()

    for {
        snap, err := iter.Next()
        if err == iterator.Done {
            break
        }
        if err != nil {
            return c.JSON(http.StatusInternalServerError, gin.H{"error": "query failed"})
        }
        return c.JSON(http.StatusOK, snap.Data())
    }
    return c.JSON(http.StatusNotFound, gin.H{"error": "user not found"})
}

3. Sanitize data before storage or secondary processing

If you store or process data that may later be used in XPath-like evaluations (e.g., XML exports), ensure that sensitive or structured fields are escaped or transformed. For XML exports derived from Firestore, apply proper encoding before evaluation.

// Example: sanitizing a string before using in an XPath context (pseudocode for illustration)
// Use a dedicated XML/HTML escaping library appropriate for your runtime
safeValue := template.HTMLEscapeString(userSupplied)
// safeValue can now be used in contexts where special characters must not break expression structure

By combining strict input validation, allowlists, and Firestore’s native query APIs, you eliminate the conditions that enable injection. middleBrick can help verify these protections by scanning endpoints and confirming that malformed or malicious inputs do not alter intended behavior.