Crlf Injection in Gin with Api Keys

Crlf Injection occurs when user-controlled data is reflected in HTTP headers without sanitization, allowing an attacker to inject additional header lines via carriage return (\r) and line feed (\n) sequences. In the Gin framework, this commonly arises when API keys or other client-supplied values are placed into response headers, authorization headers, or custom headers without validation. Because HTTP headers are newline-delimited, a payload such as Authorization: Bearer abc123\r\nX-Injected: true can split the header stream and introduce a second header controlled by the attacker.

When an API key mechanism passes a key directly into a header—either via gin.H{"X-API-Key": key} or by using the key to select a downstream target—Gin may reflect that key into a header in a way that does not sanitize \r and \n. This enables header smuggling, response splitting, or cache poisoning depending on placement. For example, if middleware reads an API key from a query parameter and sets it in a custom header without validation, an attacker can inject newline sequences to append Set-Cookie or Location headers, altering the intended routing or authentication behavior without needing to break the outer request/response structure.

In the context of authentication via API keys, Crlf Injection can bypass intended access controls or leak information. If a Gin route uses an API key to gate behavior and reflects the key in a header, an attacker can inject crafted lines that cause the server to forward requests to an unintended host (SSRF), expose internal routes, or manipulate logging and monitoring. Because the API key itself is treated as trusted data, developers may not consider that the key can be weaponized when combined with injected newline sequences. The risk is particularly acute when keys are used to construct authorization or redirection headers, as newline characters enable the attacker to terminate the intended header and begin a new one, violating the expected one-to-one mapping between client intent and server action.

Middleware that processes API keys should treat them as untrusted input. Even if the API key is validated against a database, its reflected representation in headers must be sanitized or strictly encoded to disallow control characters. Failing to do so turns a controlled credential into a vector for protocol-level attacks that manipulate the structure of the HTTP message itself.

Remediation focuses on preventing newline characters from being interpreted as header delimiters. The safest approach is to reject API keys that contain carriage return or line feed characters and to avoid reflecting raw keys in headers altogether. When reflection is necessary, encode or transform the key so that it cannot introduce newlines.

Below are concrete Gin code examples that demonstrate secure handling of API keys.

1. Reject keys containing CR or LF

func ValidateAPIKey(c *gin.Context) {
    key := c.Query("api_key")
    if strings.ContainsAny(key, "\r\n") {
        c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "invalid api key"})
        return
    }
    // proceed with key validation
    if !isValidKey(key) {
        c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "invalid api key"})
        return
    }
    c.Set("api_key", key)
    c.Next()
}

2. Use a fixed mapping instead of reflection

Do not set headers with the raw key. If you must associate metadata with the key, use an internal map and set only safe, non-user-controlled values.

var keyToOrg = map[string]string{
    "abc123": "org-123",
    "def456": "org-456",
}

func ResolveOrg(c *gin.Context) {
    key := c.Query("api_key")
    if strings.ContainsAny(key, "\r\n") {
        c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "invalid api key"})
        return
    }
    org, ok := keyToOrg[key]
    if !ok {
        c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "invalid api key"})
        return
    }
    c.Set("org_id", org)
    // Do NOT do: c.Header("X-Org-Key", key)
    c.Next()
}

3. Encode if reflection is unavoidable

If you must include the key in a header, encode it so that CR/LF cannot break the header structure. Base64 is suitable for opaque values; avoid putting raw keys in headers.

import "encoding/base64"

func SafeHeader(c *gin.Context) {
    key := c.Query("api_key")
    if strings.ContainsAny(key, "\r\n") {
        c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "invalid api key"})
        return
    }
    encoded := base64.StdEncoding.EncodeToString([]byte(key))
    c.Header("X-API-Key-Encoded", encoded)
    c.Next()
}

4. Validate early in the middleware chain

Place API key validation before any routing or business logic. This ensures malformed or dangerous keys are rejected before they influence headers or downstream calls.

func APIKeyMiddleware() gin.HandlerFunc {
    return func(c *gin.Context) {
        key := c.GetHeader("X-API-Key")
        if key == "" {
            c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "missing api key"})
            return
        }
        if strings.ContainsAny(key, "\r\n") {
            c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "invalid api key"})
            return
n        }
        // Additional checks (e.g., lookup, scope validation)
        c.Next()
    }
}

By combining strict character validation with avoidance of raw key reflection, you mitigate Crlf Injection risks specific to API key handling in Gin. These patterns align with secure handling of credentials and reduce the likelihood of protocol-level attacks that exploit newline characters in HTTP headers.