Crlf Injection in Echo Go with Api Keys

Crlf Injection occurs when an attacker can inject carriage return (CR, \r) and line feed (\n) characters into an HTTP header or response. In the Echo Go framework, this often arises when API keys or other user-controlled data are reflected in headers such as X-API-Key without proper sanitization. If an API key contains or is concatenated with user input that includes \r\n sequences, an attacker can inject additional headers or split the response, leading to HTTP response splitting, header manipulation, or cache poisoning.

Consider an Echo handler that sets a custom header using the API key provided by the client:

package main

import (
    "net/http"
    "github.com/labstack/echo/v4"
)

func main() {
    e := echo.New()
    e.GET("/resource", func(c echo.Context) error {
        apiKey := c.QueryParam("api_key")
        c.Response().Header().Set("X-API-Key", apiKey)
        return c.String(http.StatusOK, "OK")
    })
    e.Start(":8080")
}

If the API key value supplied by the caller contains CRLF characters, for example abc123\r\nX-Injected: malicious, the resulting header block sent to the client will include an extra header X-Injected: malicious. This can enable response splitting, where an attacker forces the server to embed crafted content or HTTP responses, potentially exposing sensitive information or manipulating downstream caches.

The risk is amplified when the API key is used in other unsafe contexts, such as being logged in server responses or reflected in JSON bodies without escaping. An attacker might submit an API key like key\r\nContent-Length: 0\r\n\r\n to manipulate the framing of the HTTP message. Because Echo Go does not inherently sanitize header values, developers must explicitly validate and encode any user-controlled data before it touches headers or response bodies.

To prevent Crlf Injection when working with API keys in Echo Go, treat all external input as untrusted and sanitize before use. The safest approach is to reject API keys that contain control characters or to strictly enforce a known-good pattern (e.g., alphanumeric with limited symbols). Additionally, avoid directly reflecting untrusted values in headers; if reflection is necessary, strip or encode CR and LF characters.

Example of a safe handler that validates the API key and avoids header injection:

package main

import (
    "net/http"
    "regexp"
    "strings"
    "github.com/labstack/echo/v4"
)

var apiKeyPattern = regexp.MustCompile(`^[A-Za-z0-9\-._~]+$`)

func isValidAPIKey(key string) bool {
    if strings.ContainsAny(key, "\r\n") {
        return false
    }
    return apiKeyPattern.MatchString(key)
}

func main() {
    e := echo.New()
    e.GET("/resource", func(c echo.Context) error {
        apiKey := c.QueryParam("api_key")
        if !isValidAPIKey(apiKey) {
            return c.String(http.StatusBadRequest, "invalid api_key")
        }
        // Use a sanitized value or the original only when safe
        c.Response().Header().Set("X-API-Key", apiKey)
        return c.String(http.StatusOK, "OK")
    })
    e.Start(":8080")
}

For production use, consider leveraging middleware that normalizes or rejects dangerous characters across all requests. If you must pass the API key in headers, ensure that any user-controlled components are percent-encoded or otherwise escaped. This prevents injected CRLF pairs from being interpreted as header delimiters.

When integrating with external services, avoid concatenating raw API keys into header values constructed from multiple sources. Instead, use structured, typed configuration and validate against a strict allowlist. This reduces the likelihood of accidental injection via crafted API keys or manipulated request parameters.