Header Injection in Echo Go with Firestore

Header Injection occurs when untrusted input is reflected into HTTP response headers without validation or sanitization. In an Echo Go service that integrates with Google Firestore, this typically arises when request parameters, such as a document ID or a user-controlled query field, are used to construct Firestore document paths or metadata and then echoed back into headers like X-Document-ID or X-Collection. Because Firestore paths are hierarchical and can include forward slashes, an attacker can inject additional headers or even newline characters to inject malicious headers such as Location or Set-Cookie, leading to HTTP response splitting or header manipulation.

The risk is compounded when the application uses Firestore client libraries to retrieve a document and then directly copies a field (for example, DisplayName) into a response header. If the field contains newline or carriage return characters, it can break header parsing and enable injection. Although Firestore itself does not execute injected content, the combination of Echo Go’s flexible routing and Firestore’s document-based model can expose a wider attack surface if inputs are not strictly validated before being reflected.

Consider a route /api/user/:userID where userID is used both to fetch a Firestore document and to set a custom header. If the userID contains a newline and the application sets res.Header().Set("X-User", userID), the injected newline can allow a second header to be appended. This scenario does not require authentication because the endpoint is unauthenticated, and middleBrick would flag it under its Authentication and BOLA/IDOR checks. The scanner also tests for Input Validation and Data Exposure, highlighting places where user-controlled data reaches headers without sanitization.

In the context of compliance mappings, such a flaw may intersect with OWASP API Top 10:2023 — API1:2023 Broken Object Level Authorization (if the injected header leads to IDOR) and API9:2023 Improper Assets Management (if paths become manipulable). While Firestore rules protect document access, they do not mitigate header-level injection; that responsibility lies with the API layer in Echo Go. middleBrick’s LLM/AI Security checks do not apply here, but its standard scans will identify the presence of unvalidated inputs reflected in headers and provide prioritized findings with remediation guidance.

Remediation focuses on strict input validation, avoiding header reflection of untrusted data, and using Firestore APIs safely. Do not directly set request-derived values into HTTP headers. If metadata must be returned, derive it from a trusted source or encode/transform it safely.

Below is a vulnerable example followed by a corrected implementation.

// Vulnerable: echoing user input into a header and using it in Firestore lookup
func getUser(c echo.Context) error {
    userID := c.Param("userID") // attacker-controlled
    // Unsafe: using raw userID in a header
    c.Response().Header().Set("X-User-ID", userID)

    ctx := context.Background()
    client, err := firestore.NewClient(ctx, "my-project-id")
    if err != nil {
        return c.String(http.StatusInternalServerError, "failed to create client")
    }
    defer client.Close()

    docRef := client.Collection("users").Doc(userID) // Firestore path injection risk
    doc, err := docRef.Get(ctx)
    if err != nil {
        return c.String(http.StatusInternalServerError, "failed to fetch document")
    }
    if doc.Data() == nil {
        return c.NoContent(http.StatusNotFound)
    }
    return c.JSON(doc.Data())
}

Issues in the vulnerable code:

• userID is placed directly into a response header, enabling header injection if it contains newline or carriage return characters.
• userID is used in a Firestore document path without validation, which could allow path manipulation (e.g., users/../../../other) if not constrained by Firestore rules, though Firestore will typically reject invalid paths at the server side.

Corrected version with validation and safe practices:

// Secure: validate input, avoid header reflection of raw input, use Firestore safely
func getUserSecure(c echo.Context) error {
    userID := c.Param("userID")

    // Validate: allow only alphanumeric, underscore, hyphen; reject newlines
    matched, err := regexp.MatchString(`^[a-zA-Z0-9_-]+$`, userID)
    if err != nil || !matched {
        return c.String(http.StatusBadRequest, "invalid user ID")
    }

    ctx := context.Background()
    client, err := firestore.NewClient(ctx, "my-project-id")
    if err != nil {
        return c.String(http.StatusInternalServerError, "failed to create client")
    }
    defer client.Close()

    docRef := client.Collection("users").Doc(userID)
    doc, err := docRef.Get(ctx)
    if err != nil {
        return c.String(http.StatusInternalServerError, "failed to fetch document")
    }
    if doc.Data() == nil {
        return c.NoContent(http.StatusNotFound)
    }

    // Safe: do not reflect userID into headers; if needed, use a transformed value
    safeID := "user_" + userID
    c.Response().Header().Set("X-Safe-User-ID", safeID)

    return c.JSON(doc.Data())
}

Key remediation steps:

• Validate input against a strict allowlist (e.g., alphanumeric, underscore, hyphen) before using it in Firestore paths or headers.
• Never set raw user input into HTTP response headers; if header metadata is required, transform or derive it from trusted sources.
• Use Firestore document IDs as keys without additional path traversal; rely on Firestore’s built-in document ID validation rather than manual path construction.
• Apply principle of least privilege to the Firestore service account used by the Go service, limiting write and read scope to necessary collections.

These changes address both the header injection risk and improper use of Firestore paths while preserving functionality. middleBrick’s scans will verify that headers no longer reflect raw input and that input validation is in place, providing findings mapped to relevant compliance controls.