Xss Cross Site Scripting in Gorilla Mux with Api Keys

Cross-site scripting (XSS) in a Gorilla Mux route that uses API keys can occur when user-controlled data is reflected into an HTML response without proper encoding and the API key is handled in a way that aids an attacker’s workflow. Gorilla Mux is a URL router and matcher for Go; it does not automatically sanitize output, so the framework simply passes matched variables and headers into your handler. If a handler embeds query parameters, headers, or custom claims from the API key (such as a user identifier or role) into an HTML page without escaping, reflected XSS becomes possible.

An API key is often transmitted via a query string or a custom header. In development or debugging endpoints, it is sometimes echoed back in JSON or HTML, which provides an easy injection vector. For example, a route like /profile?api_key=USER_KEY could bind the key value to a template that prints it directly. If the key or a parameter derived from it is rendered unescaped in JavaScript context or as HTML, an attacker can deliver a reflected payload such as ?api_key='><svg/onload=alert(1). Because Gorilla Mux matches the route and forwards the request, the handler may treat the key as trusted data, leading to stored or reflected XSS when the key is persisted or reflected in a page that other users view.

Another scenario involves authorization logic based on API key claims. If claims extracted from the key are placed into HTML attributes or event handlers without escaping, an attacker may leverage stored XSS to execute script in the context of other users who have permissions tied to that claim. The interaction between routing patterns, key extraction, and response generation is where the risk materializes: the key itself is not malicious, but its use in constructing dynamic content without context-aware escaping creates exploitable injection points aligned with OWASP API Top 10:2023 – Broken Object Level Authorization and Injection.

Real-world attack patterns reference known injection vectors such as <script>alert(document.cookie)</script> or SVG-based events like <svg/onload=alert(1)>. These payloads can be introduced via parameters that are improperly validated. SSRF considerations do not directly mitigate XSS, and scanning with middleBrick helps detect such unescaped reflections in the unauthenticated attack surface by correlating spec definitions with runtime behavior.

Remediation centers on strict input validation, context-aware output encoding, and avoiding the reflection of API key material in HTML. Always treat API key values as opaque strings and never embed them into HTML, JavaScript, or CSS. If you need to pass identifiers to frontend code, use opaque session tokens mapped server-side instead of exposing raw keys.

Use Go’s html/template package which auto-escapes variables by default. Do not use text/template for HTML output. Ensure that any data derived from query parameters or headers is validated and encoded based on the context (HTML body, attribute, JavaScript URL) before inclusion.

Example of a vulnerable pattern to avoid:

func ProfileHandler(w http.ResponseWriter, r *http.Request) {
    vars := mux.Vars(r)
    apiKey := r.URL.Query().Get("api_key")
    // Dangerous: directly embedding user-controlled data into HTML
    tmpl := template.Must(template.New("profile").Parse(`
      <p>Your key: {{.Key}}</p>
      <div>{{.Name}}</div>
    `))
    data := map[string]string{
        "Key": apiKey,
        "Name": vars["name"],
    }
    tmpl.Execute(w, data)
}

Corrected version with encoding and no key reflection:

func ProfileHandler(w http.ResponseWriter, r *http.Request) {
    // Validate API key format, but do not reflect it
    apiKey := r.URL.Query().Get("api_key")
    if !isValidAPIKey(apiKey) {
        http.Error(w, "Unauthorized", http.StatusUnauthorized)
        return
    }
    // Derive a user-safe identifier without exposing the key
    user, err := getUserFromKey(apiKey)
    if err != nil {
        http.Error(w, "Forbidden", http.StatusForbidden)
        return
    }
    // Safe: using html/template with context-aware escaping
    tmpl := template.Must(template.New("profile").Parse(`
      <p>Welcome, {{.Name}}</p>
    `))
    data := struct{ Name string }{Name: html.EscapeString(user.Name)}
    tmpl.Execute(w, data)
}
func isValidAPIKey(key string) bool {
    // e.g., regex for expected key format
    return regexp.MustCompile(`^[A-Za-z0-9\-_=]+\.[A-Za-z0-9\-_]+\.?[A-Za-z0-9\-_]*$`).MatchString(key)
}

Additional hardening steps include using the Secure flag and HttpOnly attribute on cookies, enforcing strict Content Security Policy headers to limit inline script execution, and validating origins for CORS when exposing endpoints to browsers. MiddleBrick scans can surface places where key values appear in responses, guiding targeted fixes.