Llm Data Leakage in Gin with Basic Auth

When an API built with the Gin framework exposes an unauthenticated or poorly protected LLM endpoint while using HTTP Basic Authentication in a non-secure way, the combination can lead to LLM data leakage. middleBrick flags this as an LLM/AI Security finding because system prompts, user prompts, or model outputs may be exposed through the API surface.

Gin is a high-performance HTTP web framework written in Go. If routes that interact with LLM services do not enforce strict authentication and authorization, or if they forward credentials or sensitive payloads to the LLM provider without protection, leakage can occur. Basic Auth credentials are base64-encoded, not encrypted; if transmitted over non-TLS channels or logged inadvertently, they become a vector. middleBrick’s active prompt injection tests check whether authentication headers or user input can be manipulated to cause the LLM to reveal its system prompt or training-sensitive information.

In a Gin handler, developers sometimes pass raw user input directly to an LLM client without sanitization. For example, a route like /ask that accepts a JSON body with a query field and forwards it to an LLM without validating or redacting sensitive context may leak internal instructions when an attacker uses prompt injection techniques. middleBrick’s LLM/AI Security checks include system prompt leakage detection (27 regex patterns), active prompt injection probing (five sequential probes), and output scanning for PII, API keys, or executable code. If the Gin endpoint is unauthenticated or weakly authenticated, these tests can expose whether the endpoint leaks model internals through crafted inputs.

Basic Auth in Gin is often implemented by checking the Authorization header manually or via middleware. If this check is missing or bypassed on endpoints that interact with LLMs, unauthenticated LLM endpoint detection becomes possible. An attacker could send requests without credentials and still receive model outputs that should be restricted. Additionally, if the handler logs requests including headers, base64-encoded credentials might be persisted in logs, further increasing data exposure risk.

middleBrick scans the unauthenticated attack surface by default, testing endpoints without credentials. For a Gin API using Basic Auth, this means the scanner will attempt to reach LLM-related routes without supplying the Authorization header. If the route responds with model data, the scan reports an unauthenticated LLM endpoint finding. The scan also cross-references OpenAPI specs; if the spec describes an LLM endpoint but the runtime allows access without proper authentication, the mismatch is highlighted.

Remediation guidance centers on enforcing authentication before LLM interactions, protecting credentials in transit and at rest, and validating/sanitizing all inputs. Use middleware to require valid Basic Auth credentials on sensitive routes, ensure TLS is mandatory, avoid logging authorization headers, and treat LLM responses as potentially sensitive. Do not rely on obscurity; explicitly secure endpoints that invoke LLMs and apply input validation to reduce prompt injection risks.

To mitigate LLM data leakage in Gin when using Basic Auth, enforce authentication rigorously around LLM routes, protect credentials, and avoid unsafe patterns. Below are concrete, working examples that demonstrate secure handling.

1. Require Basic Auth on LLM routes using middleware

Implement a middleware that validates the Authorization header before allowing the request to proceed. If credentials are missing or invalid, respond with 401.

func BasicAuthMiddleware() gin.HandlerFunc {
    return func(c *gin.Context) {
        user, pass, ok := c.Request.BasicAuth()
        if !ok || !checkCredentials(user, pass) {
            c.Header("WWW-Authenticate", `Basic realm="restricted", charset="UTF-8"`)
            c.AbortWithStatusJSON(401, gin.H{"error": "authorization required"})
            return
        }
        c.Next()
    }
}

func checkCredentials(user, pass string) bool {
    // Replace with secure lookup, e.g., constant-time comparison against a store
    return user == "apiuser" && pass == "S3cur3P@ss!"
}

2. Apply middleware only to sensitive routes

Do not globally enforce Basic Auth if public endpoints are needed. Attach the middleware selectively to routes that interact with LLMs or access sensitive data.

func setupRoutes() *gin.Engine {
    r := gin.Default()
    // Public route
    r.GET("health", func(c *gin.Context) { c.JSON(200, gin.H{"status": "ok"}) })

    // Protected LLM route
    auth := r.Group("")
    auth.Use(BasicAuthMiddleware())
    {
        auth.POST("/ask", askHandler)
    }
    return r
}

3. Securely integrate with an LLM client in a handler

Validate and sanitize input before forwarding to the LLM. Do not log credentials or raw prompts that may contain sensitive context.

type AskRequest struct {
    Query string `json:"query" binding:"required,max=200"`
}

func askHandler(c *gin.Context) {
    var req AskRequest
    if err := c.ShouldBindJSON(&req); err != nil {
        c.JSON(400, gin.H{"error": "invalid request"})
        return
    }

    // Sanitize input: remove or redact sensitive patterns if needed
    safeQuery := sanitizeInput(req.Query)

    // Call LLM client (pseudocode: replace with actual SDK)
    resp, err := callLLM(safeQuery)
    if err != nil {
        c.JSON(500, gin.H{"error": "llm error"})
        return
    }

    // Do not log req.Query if it may contain sensitive information
    c.JSON(200, gin.H{"response": resp})
}

func sanitizeInput(input string) string {
    // Implement pattern removal or redaction as required
    return input
}

4. Enforce TLS and avoid logging secrets

Ensure the server uses TLS to protect credentials in transit. Avoid logging the Authorization header or raw prompts that could contain PII or API keys. Configure your HTTP server and logging pipeline accordingly.

5. Scope credentials and rotate secrets

Use distinct credentials for different environments and rotate them regularly. Do not embed secrets in source code; use environment variables or a secure vault and load them at runtime.