Log Injection in Fiber with Basic Auth

Log injection occurs when untrusted input is written directly into log entries without sanitization, allowing an attacker to forge log lines, obfuscate events, or inject newline characters that break log structure. In Fiber, a high-performance web framework for Go, this risk is amplified when Basic Authentication is used because the framework often parses and forwards the Authorization header to logging middleware. If the header value is logged verbatim, an attacker can embed carriage returns or newlines (CRLF) to append fake entries such as fabricated user IDs or transaction statuses. For example, a crafted header like Authorization: Basic dGVzdDp0aGlz followed by %0d%0aX-Forwarded-For: 1.2.3.4 can result in log entries that appear to originate from a trusted source. This becomes particularly dangerous when logs are aggregated into SIEM systems or monitoring dashboards, because the injected lines may be interpreted as legitimate events, complicating incident response. The combination of Fiber’s flexible middleware chain and Basic Auth’s base64-encoded credentials in headers creates a scenario where untrusted data from the authorization flow can propagate into application or system logs if input validation is absent. Even though Base64 encoding is not encryption, the decoded username and password can still be logged unsafely, exposing patterns that help attackers refine brute-force or credential-stuffing attempts. Because middleBrick scans unauthenticated attack surfaces, it flags such log injection risks under the Data Exposure and Input Validation checks, highlighting how headers derived from authentication mechanisms may reach log sinks without normalization.

To mitigate log injection in Fiber with Basic Auth, treat the Authorization header as untrusted input and sanitize it before any logging. Avoid logging raw header values; instead, extract only the necessary metadata (such as whether authentication succeeded) and discard or encode potentially dangerous characters. Below are two concrete approaches with valid Go code examples using the Fiber framework.

Approach 1: Redact and log a normalized event

Replace the raw header with a structured log entry that records authentication outcomes without echoing user input. Use a fixed string for credentials and rely on request-scoped identifiers that do not originate from the client.

// Example using Fiber with structured logging
package main

import (
	"log"
	"strings"

	"github.com/gofiber/fiber/v2"
)

func main() {
	app := fiber.New()

	app.Use(func(c *fiber.Ctx) error {
		auth := c.Get("Authorization")
		// Redact raw credentials before any logging
		if strings.HasPrefix(auth, "Basic ") {
			log.Printf("auth_event=basic_auth status=attempted username=redacted")
		} else {
			log.Printf("auth_event=no_auth status=missing")
		}
		return c.Next()
	})

	app.Get("/secure", func(c *fiber.Ctx) error {
		return c.SendString("secure endpoint")
	})

	app.Listen(":3000")
}

Approach 2: Validate and sanitize before logging, using allowlists

Validate the Base64 payload only to the extent required for operational checks, and sanitize newlines before writing to logs. This prevents CRLF injection while still enabling basic observability.

// Example sanitizing function and usage in Fiber
package main

import (
	"encoding/base64"
	"log"
	"regexp"
	"strings"

	"github.com/gofiber/fiber/v2"
)

var newline = regexp.MustCompile(`[\r\n]`)

func sanitizeLogInput(s string) string {
	return newline.ReplaceAllString(s, "_")
}

func main() {
	app := fiber.New()

	app.Use(func(c *fiber.Ctx) error {
		auth := c.Get("Authorization")
		sanitized := sanitizeLogInput(auth)
		// Optionally decode to verify format without executing unsafe content
		if strings.HasPrefix(auth, "Basic ") {
			if _, err := base64.StdEncoding.DecodeString(strings.TrimPrefix(auth, "Basic ")); err != nil {
				log.Printf("auth_event=basic_auth status=invalid_token")
			} else {
				log.Printf("auth_event=basic_auth status=valid_token credential_payload=%s", sanitized)
			}
		}
		return c.Next()
	})

	app.Get("/items", func(c *fiber.Ctx) error {
		return c.SendString("items list")
	})

	app.Listen(":3000")
}

In both examples, the key remediation principle is to avoid echoing raw Authorization header values into logs. By normalizing, redacting, or sanitizing inputs that originate from authentication mechanisms, you reduce the risk that CRLF or other control characters can alter log structure. middleBrick’s checks for Data Exposure and Input Validation will highlight whether such unsanitized authentication data reaches observable outputs, and its findings include remediation guidance aligned with frameworks like OWASP API Top 10.