Log Injection in Echo Go with Api Keys

Log injection occurs when untrusted input is written directly into application logs without sanitization, enabling attackers to forge log entries, obscure real events, or inject newline characters that lead to log splicing. In the Echo Go web framework, this risk is amplified when API keys are handled carelessly. API keys are often logged for debugging or auditing, and if they arrive from client input (e.g., headers, query parameters, or request bodies) and are written directly to logs, an attacker can manipulate the key value to include newlines or structured log delimiters.

Consider an Echo handler that logs the received API key to help trace authorization failures:

func ValidateApiKey(next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        apiKey := c.Request().Header.Get("X-API-Key")
        // Unsafe: directly interpolating user-controlled input into logs
        fmt.Printf("API key received: " + apiKey + "\n")
        if !isValid(apiKey) {
            return echo.NewHTTPError(http.StatusUnauthorized, "invalid key")
        }
        return next(c)
    }
}

If an attacker sends a request with X-API-Key: abc123\nContent-Type: application/json, the newline can split the log line and cause the application to misinterpret subsequent log entries as part of the key. This is a classic log injection (log forging) scenario. In the context of middleBrick’s 12 security checks, this would surface under Input Validation and Data Exposure, with a finding that user-controlled data is written unsafely into logs, potentially enabling log forging or obscuring real events.

Additionally, when API keys are logged at multiple layers (e.g., access logs, application logs, and audit trails), an injected newline can chain across entries, making incident analysis difficult and increasing forensic noise. Because middleBrick scans the unauthenticated attack surface and tests input validation paths, it can detect whether API key inputs are reflected in responses or logs without proper sanitization, highlighting the risk even when authentication is not required to trigger the endpoint.

To prevent log injection when handling API keys in Echo Go, sanitize and validate all external input before it reaches logging statements. Do not trust header or query values; treat them as untrusted strings. Use structured logging to separate data from metadata, and avoid concatenating user input directly into log messages.

Below is a safe pattern using a sanitization helper and structured logging via key-value pairs:

import (
    "fmt"
    "net/http"
    "strings"

    "github.com/labstack/echo/v4"
)

// sanitizeLogValue removes newlines and carriage returns to prevent log injection.
func sanitizeLogValue(v string) string {
    v = strings.ReplaceAll(v, "\r", "\\r")
    v = strings.ReplaceAll(v, "\n", "\\n")
    return v
}

func ValidateApiKey(next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        apiKey := c.Request().Header.Get("X-API-Key")
        // Safe: sanitize before logging
        safeKey := sanitizeLogValue(apiKey)
        fmt.Printf("API key received: %s\n", safeKey)
        if !isValid(apiKey) {
            return echo.NewHTTPError(http.StatusUnauthorized, "invalid key")
        }
        return next(c)
    }
}

For more robust observability, use structured logging libraries (e.g., stdlib log with explicit fields, or a logging framework that supports key-value pairs) so that the API key is a distinct field rather than interpolated text:

import (
    "log"
    "os"
)

func ValidateApiKeyStructured(next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        apiKey := c.Request().Header.Get("X-API-Key")
        // Structured logging avoids concatenation risks
        log.Println("API key received", "api_key", apiKey)
        if !isValid(apiKey) {
            return echo.NewHTTPError(http.StatusUnauthorized, "invalid key")
        }
        return next(c)
    }
}

When using the middleBrick CLI to scan this service, you can verify that your endpoints properly handle API key inputs. Run middlebrick scan <your-url> from the terminal to generate a report that highlights input validation and data exposure findings. Teams on the Pro plan can enable continuous monitoring to detect regressions, and those using the GitHub Action can fail builds if security scores drop below their chosen threshold.