Xml External Entities in Gorilla Mux with Mongodb

An XML External Entity (XXE) vulnerability occurs when an application processes XML input that references external entities. In a Gorilla Mux route, if an HTTP handler parses XML request bodies using an XML parser configured to resolve external entities, and that handler subsequently interacts with a Mongodb database, the combination can expose sensitive internal data or enable server-side request forgery. This typically happens when the parser is not explicitly configured to disable external entity resolution. For example, an attacker may send an XML payload that references a file such as /etc/passwd or an internal metadata service endpoint, causing the parser to read and exfiltrate that content back to the attacker. If the application then stores or logs parts of the response in Mongodb, the data may be persisted in an exposed collection.

Gorilla Mux does not parse XML by itself; it passes the request to your handler. Therefore, the risk arises from how your handler unmarshals the XML. Commonly, developers use libraries such as encoding/xml in Go without disabling DTD processing and external entity resolution. When such unmarshaled data is later used to build database operations against Mongodb—such as inserting user-controlled values into a collection—unsafe data may trigger further issues like injection or exposure of internal network information via SSRF-like paths referenced in the entities.

In a typical vulnerable setup, an XML request body might include a DOCTYPE declaration defining an external entity that points to the local Mongodb metadata endpoint or a file on disk. Because the handler trusts the XML parser’s output, the application may inadvertently send that resolved content as part of a query or update to Mongodb. Even though Mongodb itself does not process XML, the vulnerability chain is completed when the application uses attacker-influenced data in database operations, such as constructing a filter or update document from parsed XML fields without proper validation.

Middleware components like authentication or logging may also parse XML before the request reaches your Gorilla Mux handler. If those components resolve entities, the risk surface expands further. Additionally, if your service exposes an unauthenticated endpoint that accepts XML, the attack surface increases because attackers do not need prior access to craft malicious XML containing external entity references.

Because middleBrick scans unauthenticated attack surfaces, it can detect endpoints that accept XML and inspect whether external entity resolution is disabled. During a scan, it may submit controlled XML inputs and observe responses for indicators such as filesystem content or internal host references, which would suggest XXE. Findings are mapped to relevant standards such as OWASP API Top 10 and provide remediation guidance, helping you identify and mitigate the issue before exploitation occurs.

To secure Gorilla Mux handlers that interact with Mongodb, you must ensure XML parsing does not resolve external entities and that data flowing into Mongodb operations is strictly validated. Below is a safe pattern using Go’s encoding/xml with a custom decoder that disables DTD and external entity resolution.

import (
    "encoding/xml"
    "net/http"
    "github.com/gorilla/mux"
)

type SafePayload struct {
    Field1 string `xml:"field1" json:"field1"`
    Field2 string `xml:"field2" json:"field2"`
}

func safeXMLHandler(w http.ResponseWriter, r *http.Request) {
    // Limit the size of the request body to prevent resource exhaustion
    r.Body = http.MaxBytesReader(w, r.Body, 1048576) // 1 MB
    decoder := xml.NewDecoder(r.Body)
    // Disable DTD and external entities
    decoder.Entity = xml.HTMLEntity
    var payload SafePayload
    if err := decoder.Decode(&payload); err != nil {
        http.Error(w, "Invalid XML", http.StatusBadRequest)
        return
    }

    // Validate fields before using them
    if payload.Field1 == "" || payload.Field2 == "" {
        http.Error(w, "Missing required fields", http.StatusBadRequest)
        return
    }

    // Example Mongodb insert using a secure, validated payload
    // collection.InsertOne(context.TODO, bson.M{
    //     "field1": payload.Field1,
    //     "field2": payload.Field2,
    // })

    w.WriteHeader(http.StatusOK)
}

Key remediation steps:

• Disable external entity resolution by customizing the XML decoder or using a secure parser that does not process DOCTYPEs.
• Set reasonable size limits on request bodies to mitigate XXE-based denial-of-service attempts.
• Validate and sanitize all data before constructing Mongodb operations. Do not directly embed unvalidated XML node content into database queries.
• If you must accept complex XML, consider transforming it into a strict schema (e.g., using XSD) and validating against it before processing.
• Avoid using reflection-based unmarshaling options that may silently follow external entity references.

Even when using Mongodb, which stores JSON-like documents, ensure that any data derived from XML is treated as untrusted input. Use structured structs with explicit tags and avoid concatenating raw XML strings into database commands. Applying these practices reduces the risk of data exposure via Mongodb collections and prevents attackers from leveraging your XML parsing logic for information leakage or SSRF-style interactions with internal services.