Log Injection in Fiber with Firestore

Log injection occurs when untrusted input is written directly into log entries without proper sanitization or formatting control. In a Fiber application that uses Firestore as a backend data store, this typically arises when request-derived data—such as user IDs, query parameters, or request IDs—are embedded into log statements without validation or escaping. Because Firestore operations often include structured metadata (e.g., document IDs, collection names, and query filters), these values can become part of application logs when developers log Firestore interactions for observability.

For example, a developer might write a log line that includes a Firestore document ID directly from user input:

app.Get("/users/:userID", func(c *fiber.Ctx) error {
    userID := c.Params("userID")
    log.Printf("Fetching user document: %s", userID)
    ctx := context.Background()
    _, err := client.Collection("users").Doc(userID).Get(ctx)
    if err != nil {
        log.Printf("Firestore error: %v", err)
        return c.SendStatus(fiber.StatusInternalServerError)
    }
    return c.SendStatus(fiber.StatusOK)
})

If the userID contains newline characters or structured text (e.g., attacker\nMalicious: injected), the log entry can be corrupted with additional lines or false metadata. This can obscure the original log context, complicate log parsing, and in some log aggregation setups, enable log forging that may affect downstream monitoring or alerting systems. In environments where logs are correlated with Firestore operation identifiers, injected content might simulate structured fields, leading to confusion during incident investigations.

Because Firestore document IDs and query parameters often reflect user-controlled input, the risk is elevated when logging is performed at a verbose level without normalization. The log entries may appear consistent visually, but programmatic log analysis tools can misinterpret injected newlines or key-value patterns, effectively turning the log stream into a vector for obfuscation or injection-based attacks. This is especially relevant when logs are used for security monitoring, where anomalous entries might be overlooked due to format manipulation.

middleBrick detects log injection risks as part of its Input Validation and Unsafe Consumption checks. When scanning a Fiber endpoint that logs Firestore interactions, it evaluates whether structured or untrusted input is reflected in log output without sanitization. The scanner does not alter runtime behavior but highlights how attacker-controlled data can reach logs and recommends normalization, strict formatting, and structured logging practices to preserve log integrity.

To mitigate log injection in Fiber applications using Firestore, you should sanitize and structure any data derived from user input before it reaches log statements. This includes document IDs, collection names, query parameters, and error messages that may contain Firestore-specific metadata.

A robust approach involves normalizing input and using structured logging with explicit field separation. For example, instead of directly interpolating raw IDs into log messages, use a consistent encoding and log key-value pairs explicitly:

import (
    "context"
    "log"
    "net/url"
    "strings"

    "github.com/gofiber/fiber/v2"
    "cloud.google.com/go/firestore"
)

func sanitizeLogInput(raw string) string {
    // Remove newlines and control characters that can break log structure
    cleaned := strings.ReplaceAll(raw, "\n", "")
    cleaned = strings.ReplaceAll(cleaned, "\r", "")
    cleaned = url.QueryEscape(cleaned)
    return cleaned
}

func safeFirestoreHandler(client *firestore.Client) fiber.Handler {
    return func(c *fiber.Ctx) error {
        userID := sanitizeLogInput(c.Params("userID"))
        log.Printf("firestore_operation=document_get collection=users document_id=%s", userID)

        ctx := context.Background()
        docSnap, err := client.Collection("users").Doc(c.Params("userID")).Get(ctx)
        if err != nil {
            log.Printf("firestore_operation=error collection=users document_id=%s error=%v", userID, err)
            return c.SendStatus(fiber.StatusInternalServerError)
        }
        log.Printf("firestore_operation=document_found collection=users document_id=%s exists=%t", userID, docSnap.Exists())
        return c.JSON(docSnap.Data())
    }
}

This pattern ensures that newline and carriage-return characters are replaced with placeholders, and URL encoding prevents injection of additional structured tokens. The log line uses explicit keys (firestore_operation, collection, document_id) so that log parsers can reliably separate fields even if the data contains unusual characters.

For error handling, avoid exposing raw Firestore errors directly in logs without sanitization. Instead, normalize error messages and include context via structured fields:

func logFirestoreError(err error, userID string) {
    safeID := sanitizeLogInput(userID)
    log.Printf("firestore_operation=error document_id=%s error_type=%s error_code=%d", safeID, err.Error(), -1)
}

By consistently applying these practices across all Firestore interactions in Fiber routes, you reduce the risk of log injection while preserving the observability value of your logging system. middleBrick’s scans can validate whether such sanitization is present in your endpoints by checking for reflective logging of untrusted input and suggesting improvements aligned with secure logging standards.