Llm Data Leakage in Gorilla Mux (Go)

When building Go services that expose LLM endpoints, using Gorilla Mux for routing can inadvertently create data leakage risks if route variables, query parameters, or request bodies are handled without care. Because LLM endpoints often receive highly sensitive prompts, system instructions, or user data, any uncontrolled exposure through routing or logging can lead to PII, API keys, or internal logic being revealed in model outputs or server logs.

In Gorilla Mux, routes are typically defined with path parameters (e.g., /api/llm/{provider}/chat). If handlers extract these parameters and inadvertently include them in responses, error messages, or passed to downstream LLM calls without sanitization, sensitive routing context may leak into model context or logs. Additionally, developers might attach metadata such as tenant IDs or trace IDs as request context values; if these values are later surfaced in LLM responses (for example, via verbose error reporting or reflection in generated text), the system can disclose internal routing or organizational structure.

Another leakage vector arises from reflection-based handler registration or middleware that logs request bodies for debugging. If a middleware logs full request payloads containing user prompts and those logs are later inspected or exposed (for example, through an error page or a trace included in LLM output), confidential data can be surfaced. Similarly, if handlers pass the full HTTP request context into the LLM generation pipeline (for example by forwarding headers or URL segments as part of the prompt), the model may regurgitate route-specific details in its responses.

These risks are compounded when using unauthenticated LLM endpoints, as middleBrick’s LLM/AI Security checks specifically detect endpoints that expose system prompts or allow prompt injection. Gorilla Mux routes that directly forward user input to LLM providers without strict input validation and output scanning increase the chance that injected prompts or malformed payloads trigger unintended data exposure through model outputs.

To illustrate, consider a route that accepts a user query and forwards it to an LLM. If the handler embeds the route’s provider variable into the context sent to the model, and the model is not properly constrained, it might echo that provider name alongside sensitive instructions or internal notes. This becomes a leakage channel where routing topology is unintentionally revealed through the LLM’s responses.

Remediation centers on strict input validation, avoiding the propagation of route variables or request metadata into LLM prompts or responses, and ensuring that sensitive data is never reflected back through the model. Below are concrete, safe patterns for Gorilla Mux handlers in Go.

1. Sanitize route variables and avoid echoing them in LLM context

Do not forward raw mux.Vars values into LLM prompts or system messages. Instead, validate and use only what’s necessary.

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

func chatHandler(w http.ResponseWriter, r *http.Request) {
	vars := mux.Vars(r)
	provider := vars["provider"]
	// Validate provider against an allowlist; do not echo it into the LLM context
	allowed := map[string]bool{"openai": true, "anthropic": true}
	if !allowed[provider] {
		http.Error(w, "invalid provider", http.StatusBadRequest)
		return
	}
	// Continue with a safe, provider-agnostic LLM call
	handleLLMRequest(w, r)
}

2. Avoid logging request bodies or context metadata that may contain sensitive prompts

Use structured logging that excludes body content and does not attach sensitive fields to trace context that could leak into model outputs.

import (
	"log"
	"net/http"
)

func safeLoggingMiddleware(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		// Do NOT log r.Body directly; it may contain sensitive prompts
		// Instead, log only method and path
		log.Printf("request: %s %s", r.Method, r.URL.Path)
		next.ServeHTTP(w, r)
	})
}

3. Use strict input validation and output scanning before sending data to LLM endpoints

Validate user input, and apply output scanning to detect PII, API keys, or executable code. This aligns with middleBrick’s LLM/AI Security checks for system prompt leakage and output scanning.

func handleLLMRequest(w http.ResponseWriter, r *http.Request) {
	body, err := io.ReadAll(r.Body)
	if err != nil {
		http.Error(w, "bad request", http.StatusBadRequest)
		return
	}
	// Validate and sanitize input here (e.g., length, content-type, regex checks)
	if !isValidPrompt(body) {
		http.Error(w, "invalid input", http.StatusBadRequest)
		return
	}
	// Simulate sending to LLM; in practice, call the LLM API with a sanitized body
	resp, err := callLLM(body)
	if err != nil {
		http.Error(w, "llm error", http.StatusInternalServerError)
		return
	}
	// Scan resp for PII, API keys, or code before writing
	if containsSensitiveData(resp) {
		http.Error(w, "llm output contains sensitive data", http.StatusInternalServerError)
		return
	}
	w.Write(resp)
}

4. Isolate LLM-specific routes and enforce tight context boundaries

Define separate route scopes and avoid attaching broad request context to LLM calls. This reduces the surface for inadvertent data reflection.

func setupRoutes() *mux.Router {
	r := mux.NewRouter()
	llm := r.PathPrefix("/api/llm").Subrouter()
	llm.HandleFunc("/chat", safeLoggingMiddleware(chatHandler)).Methods("POST")
	// Do not attach global request-scoped metadata to the LLM subrouter
	return r
}