Xml External Entities in Gin with Bearer Tokens

XML External Entity (XXE) injection occurs when an application processes XML input and allows an attacker to define or reference external entities, leading to file reads, SSRF, or denial of service. In Gin, this risk can emerge when XML payloads are accepted—for example, in webhook handlers or legacy integrations—especially when requests carry Bearer Tokens in authorization headers for authentication or scope validation.

Consider a Gin endpoint that parses incoming XML while using the Bearer Token from the Authorization header to enforce per-client policies. If the XML parser is configured to process external DTDs or entities, an attacker can supply a malicious XML body that references local files or internal URLs. The Bearer Token itself does not cause the XXE, but it often travels in the same request, and logging or error handling may inadvertently couple token leakage with XML parsing behavior. For instance, verbose errors might disclose the token value, or file reads triggered by XXE could expose token storage paths or configuration files containing token validation logic. This combination becomes particularly sensitive when the endpoint trusts the token for authorization yet processes untrusted XML without disabling external entity resolution.

In practice, an attacker might send an XML body with a DOCTYPE that defines an entity pointing to /etc/hosts or to an internal metadata service reachable via SSRF, while the Authorization header carries a stolen Bearer Token. Gin’s routing and context handling will typically pass the token to business logic, and if that logic also feeds data into an XML parser without proper hardening, the token’s context may influence which files or services are accessed. Even when the token is validated before parsing, side-channel risks remain: error messages, timing differences, or audit logs might correlate token validity with parser behavior, aiding reconnaissance. Therefore, the vulnerability is not about the token format itself, but about how Gin applications handle XML input alongside authenticated requests that include Bearer Tokens.

Remediation focuses on disabling external entity processing in XML parsers and ensuring Bearer Token handling does not amplify XML-related risks. Below are concrete, safe patterns for Gin handlers.

1. Disable external entities in XML parsing

Use a secure XML decoder that disables DTD and external entity resolution. If you rely on a third-party XML library, configure it to reject external entities explicitly. For example, with encoding/xml you can unmarshal into Go structs while avoiding parser features that support external entities.

package main

import (
    "encoding/xml"
    "net/http"
    "github.com/gin-gonic/gin"
)

type Payload struct {
    Field string `xml:"field"`
}

func safeHandler(c *gin.Context) {
    // Read body without enabling DTD/external entities
    decoder := xml.NewDecoder(c.Request.Body)
    decoder.Entity = xml.HTMLEntity{} // minimal, no DTD expansion
    var p Payload
    if err := decoder.Decode(&p); err != nil {
        c.JSON(http.StatusBadRequest, gin.H{"error": "invalid xml"})
        return
    }
    // process p.Field safely
    c.JSON(http.StatusOK, gin.H{"received": p.Field})
}

func main() {
    r := gin.Default()
    r.POST("/webhook", safeHandler)
    r.Run()
}

2. Validate and isolate Bearer Token usage

Extract and validate the Bearer Token before any XML processing. Avoid using token-derived data to influence file paths or external requests. Use standard JWT parsing or introspection with strict scope checks, and keep token validation separate from XML decoding.

package main

import (
    "net/http"
    "strings"
    "github.com/gin-gonic/gin"
)

func authMiddleware() gin.HandlerFunc {
    return func(c *gin.Context) {
        auth := c.GetHeader("Authorization")
        if auth == "" {
            c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "authorization header required"})
            return
        }
        parts := strings.Split(auth, " ")
        if len(parts) != 2 || parts[0] != "Bearer" {
            c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "invalid authorization format"})
            return
        }
        token := parts[1]
        // Perform validation (e.g., JWT verification or introspection)
        // Do not use token content to guide XML parsing or file reads
        c.Set("token_valid", true) // simplified flag for example
        c.Next()
    }
}

func xmlHandler(c *gin.Context) {
    // Token was already validated by middleware
    // Proceed with safe XML decoding as shown earlier
}

func main() {
    r := gin.Default()
    r.Use(authMiddleware())
    r.POST("/webhook", xmlHandler)
    r.Run()
}

3. Defense-in-depth: input validation and secure defaults

Reject XML content types that are unnecessary, enforce tight size limits, and avoid reflecting token information in error responses. Combine these practices with continuous scanning to detect misconfigurations early.

• Do not enable xml.Decoder features that allow DTD or entity expansion.
• Set reasonable body size limits before parsing.
• Ensure error messages do not include the Bearer Token or stack traces that reference token handling code.

By decoupling authentication from XML processing and hardening the XML parser, you mitigate XXE risks while preserving legitimate use of Bearer Tokens for access control.