Formula Injection in Gorilla Mux with Firestore

Formula Injection occurs when user-controlled data is interpreted as executable logic by a downstream system. In a Gorilla Mux route that queries Firestore, this typically happens when path or query parameters are used to construct Firestore queries without validation. Firestore itself does not evaluate formulas, but if user input is concatenated into document field paths, map keys, or used to select which fields to return, an attacker can inject references to other fields or influence runtime behavior through crafted keys.

Consider a Gorilla Mux endpoint defined as /users/{userID}/profile. The handler extracts userID from the route and uses it to build a Firestore document path such as users/{userID}/settings. If userID is not strictly validated and is later used to compute a dynamic field name — for example, constructing a field name like "preferences_" + userInput — an attacker could supply a userID value that includes a dot or bracket notation, potentially traversing into sibling collections or reading unintended document fields. While Firestore’s SDKs treat these strings as literal document IDs or field names, the surrounding application logic may misuse them to conditionally include or exclude data, effectively creating a formula-like injection through uncontrolled key assembly.

Another scenario involves query parameters that influence which fields are requested from Firestore. If an endpoint accepts a fields parameter and directly appends it to a Select or projection list without allowlisting, an attacker could provide values such as email,metadata.isAdmin. The application may then expose sensitive fields or infer relationships based on presence or absence of data, a form of information leakage enabled by dynamic field selection. This becomes a risk when the handler builds the query using string concatenation or reflection based on user input, rather than using typed structures or strict allowlists.

Because middleBrick scans unauthenticated attack surfaces, it can detect endpoints where user input influences Firestore document paths or field selection without proper validation. Findings may highlight missing input validation, excessive data exposure, or unsafe consumption patterns that align with Formula Injection risks. The scanner cross-references these runtime observations with the OpenAPI spec to verify whether parameter schemas and expected formats are clearly defined, helping you identify where controls are missing.

Remediation guidance centers on strict input validation, allowlisting of field names, and avoiding dynamic construction of document paths or queries from raw user input. Use typed structures, validate against a known set of safe values, and leverage Firestore’s built-in mechanisms for accessing known document IDs rather than assembling paths from unchecked parameters. middleBrick’s LLM/AI Security checks can further verify that no prompt or configuration leakage occurs if this API is connected to AI-driven tooling.

Secure handling in Gorilla Mux begins with validating all route and query parameters before they reach Firestore. Define strict patterns for identifiers such as user IDs using regex middleware in Gorilla Mux, and reject any input that does not conform. For Firestore document references, always use known, trusted identifiers rather than concatenating user input into paths.

Example of an unsafe pattern to avoid:

// UNSAFE: dynamic field construction from user input
userInput := mux.Vars(r)["fieldKey"]
fieldPath := "userData." + userInput
docSnap, err := client.Collection("profiles").Doc(userID).Get(ctx)
if err != nil {
    http.Error(w, err.Error(), http.StatusInternalServerError)
    return
}
val := docSnap.Data()[fieldPath] // Risk: fieldPath controlled by user

Instead, use an allowlist approach to map expected keys to known Firestore field names:

// SAFE: allowlist-based field selection
userInput := mux.Vars(r)["fieldKey"]
allowedFields := map[string]string{
    "displayName": "displayName",
    "photoURL":    "photoURL",
    "role":        "role",
}
field, ok := allowedFields[userInput]
if !ok {
    http.Error(w, "invalid field", http.StatusBadRequest)
    return
}
docSnap, err := client.Collection("profiles").Doc(userID).Get(ctx)
if err != nil {
    http.Error(w, err.Error(), http.StatusInternalServerError)
    return
}
val := docSnap.Data()[field] // Safe: field is from allowlist

When constructing document paths, rely on predefined identifiers rather than runtime assembly. For example, if you need to access a user’s settings, use a fixed subcollection name and a validated user ID:

// SAFE: fixed collection with validated ID pattern
userID := mux.Vars(r)["userID"]
if !isValidUserID(userID) { // implement regex validation
    http.Error(w, "invalid user ID", http.StatusBadRequest)
    return
}
settingsRef := client.Collection("users").Doc(userID).Collection("settings").Doc("prefs")
settingsSnap, err := settingsRef.Get(ctx)
if err != nil {
    http.Error(w, err.Error(), http.StatusInternalServerError)
    return
}
settings := settingsSnap.Data()

For queries influenced by user input, prefer allowlisted field names and avoid dynamically building Firestore field paths. If you need to filter by a dynamic key, map the input to a known field constant before using it in a query or document access.