Xml External Entities in Echo Go with Firestore

An XML External Entity (XXE) vulnerability occurs when an application processes XML input that references external entities. In Go services built with the Echo framework, if XML payloads are parsed without proper safeguards and the parsed data is subsequently used to interact with Google Cloud Firestore, the combination can expose both XML parsing risks and Firestore data exposure.

Echo does not parse XML by default; developers typically add an XML binding layer (for example, using github.com/labstack/echo/v4/middleware or a custom XML unmarshal step). If that layer enables external entity processing, an attacker can supply an XML body with a malicious external entity declaration. When the XML is unmarshaled, the entity is resolved, and the attacker can cause the parser to read local files or make network requests. If the application then uses the extracted data to construct Firestore queries, the malicious content may be written to or retrieved from Firestore, potentially bypassing expected validation boundaries.

Consider an endpoint that accepts an XML document containing user profile fields and stores them in a Firestore collection. If the XML parser resolves external entities, an attacker can provide an entity that points to a sensitive file on the host (e.g., /etc/passwd). The resulting data is then sent to Firestore as a field value. While Firestore itself does not process XML, the vulnerability lies in how the Go service handles input before interacting with Firestore. A crafted XML payload can lead to unauthorized file reads, and if the application uses extracted data to dynamically build Firestore queries or document structures, it may inadvertently expose or modify data that should remain restricted.

Additionally, if the service uses Firestore Admin SDK operations based on XML-derived parameters (such as collection or document IDs), an attacker may attempt to manipulate paths or keys through external entities. This can lead to Insecure Direct Object Reference (IDOR) style impacts when combined with insufficient authorization checks. For example, an external entity could reference a path that maps to another user’s document, and if the Go code uses that parsed value directly with Firestore, it may access or write data across tenant boundaries.

Network-based XXE is also possible if the XML parser performs remote entity resolution and the Go service is reachable from within the same network as other Google Cloud services. Even though Firestore is a managed service accessed over authenticated APIs, an attacker who can trigger outbound HTTP requests from the parser may probe internal metadata services or other endpoints. The key risk in the Echo with Firestore context is that XML parsing and Firestore operations are chained in application code; weaknesses in XML handling propagate to Firestore interactions if input is not strictly validated and sanitized before use.

Real-world exploitation often follows the OWASP API Top 10:2023 category for XXE and aligns with common insecure deserialization patterns when XML binding is misconfigured. The presence of Firestore does not introduce XML parsing, but it becomes a conduit for attacker-influenced data if the Go service does not validate, restrict, or sanitize XML-derived inputs before constructing requests to Firestore.

Remediation focuses on two areas: securing XML parsing in the Echo service and ensuring Firestore interactions validate and sanitize all inputs. Below are concrete Go code examples that demonstrate a vulnerable pattern and a corrected implementation.

Vulnerable pattern

An Echo route that accepts XML and writes extracted fields to Firestore without disabling external entities:

// Vulnerable: XML parser may process external entities
func CreateProfile(c echo.Context) error {
    xmlBytes, err := io.ReadAll(c.Request().Body)
    if err != nil {
        return c.JSON(http.StatusBadRequest, map[string]string{"error": "failed to read body"})
    }

    var payload Profile
    // This unmarshal step may resolve external entities if the XML decoder is not configured safely
    if err := xml.Unmarshal(xmlBytes, &payload); err != nil {
        return c.JSON(http.StatusBadRequest, map[string]string{"error": "invalid XML"})
    }

    // Firestore interaction using extracted data without strict validation
    ctx := context.Background()
    client, err := firestore.NewClient(ctx, "my-project")
    if err != nil {
        return c.JSON(http.StatusInternalServerError, map[string]string{"error": "firestore init failed"})
    }
    defer client.Close()

    _, err = client.Collection("profiles").Doc(payload.UserID).Set(ctx, map[string]interface{}{
        "name":  payload.Name,
        "email": payload.Email,
    })
    if err != nil {
        return c.JSON(http.StatusInternalServerError, map[string]string{"error": "failed to write Firestore"})
    }

    return c.JSON(http.StatusOK, map[string]string{"status": "ok"})
}

Secured remediation

Disable external entity processing in XML parsing and validate Firestore inputs:

// Secured: restrict XML parser, validate inputs before Firestore use
func CreateProfile(c echo.Context) error {
    xmlBytes, err := io.ReadAll(c.Request().Body)
    if err != nil {
        return c.JSON(http.StatusBadRequest, map[string]string{"error": "failed to read body"})
    }

    // Create a tokenizer-based parser that does not resolve external entities
    decoder := xml.NewDecoder(bytes.NewReader(xmlBytes))
    decoder.Entity = func(e xml.Entity) { /* reject external entities */ }
    
    var payload Profile
    if err := decoder.Decode(&payload); err != nil {
        return c.JSON(http.StatusBadRequest, map[string]string{"error": "invalid XML"})
    }

    // Validate inputs before using them with Firestore
    if payload.UserID == "" || !isValidUserID(payload.UserID) {
        return c.JSON(http.StatusBadRequest, map[string]string{"error": "invalid user identifier"})
    }
    if !isValidEmail(payload.Email) {
        return c.JSON(http.StatusBadRequest, map[string]string{"error": "invalid email"})
    }

    ctx := context.Background()
    client, err := firestore.NewClient(ctx, "my-project")
    if err != nil {
        return c.JSON(http.StatusInternalServerError, map[string]string{"error": "firestore init failed"})
    }
    defer client.Close()

    // Use validated, sanitized data for Firestore operations
    _, err = client.Collection("profiles").Doc(payload.UserID).Set(ctx, map[string]interface{}{
        "name":  payload.Name,
        "email": payload.Email,
    })
    if err != nil {
        return c.JSON(http.StatusInternalServerError, map[string]string{"error": "failed to write Firestore"})
    }

    return c.JSON(http.StatusOK, map[string]string{"status": "ok"})
}

// Basic validation helpers (customize per requirements)
func isValidUserID(id string) bool {
    return len(id) > 0 && len(id) <= 128 && regexp.MustCompile(`^[a-zA-Z0-9_-]+$`).MatchString(id)
}

func isValidEmail(email string) bool {
    return email != "" && strings.Contains(email, "@")
}

Additional recommendations: apply principle of least privilege to the Firestore service account used by the Go service, and enforce strict schema validation before constructing Firestore documents. Using the middleBrick CLI (middlebrick scan <url>) or GitHub Action can help detect XXE-prone configurations and input validation gaps in your API surface, complementing these code-level fixes.