Log Injection in Fiber with Jwt Tokens

Log injection in a Fiber application that uses JWT tokens occurs when attacker-controlled data is written directly into application or security event logs without proper sanitization. This is especially risky when JWT validation, parsing, or failure events are recorded, because an attacker can embed newline characters or malicious payloads into log entries. Newline characters can enable log forging, where fake log lines appear to originate from the application or from a valid JWT authentication event. Worse, if logs are later ingested by monitoring or SIEM tools that treat newline-delimited entries as separate log records, a single forged log can split into multiple fake records, potentially mimicking successful authentication, token refresh, or authorization grants.

With JWT tokens, typical injection points include logging the raw token string, claims extracted from the token (such as subject or roles), or error messages produced when token validation fails. For example, logging the value of a header or a claim without sanitization means an attacker-supplied token containing characters like %0a (URL-encoded newline) or literal newline characters can result in log entries that appear to come from a trusted source. Consider a route that decodes a JWT and logs the subject claim:

curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ0ZXN0%0auser%3Cmalicious_payload%3E\n[attacker-supplied extra log line]" http://localhost:8080/profile

If the application logs the subject as-is, the injected newline can cause the log to be interpreted as multiple entries, and the forged line may be treated as a legitimate authentication or authorization event. In distributed setups where logs are aggregated, such forged entries can complicate incident response by obscuring the true source of an attack. Log injection in this context does not directly bypass JWT signature validation, but it undermines auditability and can be used to hide follow-on attacks or to trigger automated responses based on misleading log signals.

The risk is compounded when JWT parsing errors or exceptions are logged with the token or its claims included. An attacker can probe error handling by sending malformed tokens and observe whether token parsing exceptions are recorded verbatim, including the token header or payload. This can expose implementation details or aid in further attacks, such as determining token structure or validation logic. The key point is that JWT tokens often carry identity and authorization information; if that information is reflected in logs without validation or escaping, the logs become part of the attack surface.

To mitigate log injection when using JWT tokens in Fiber, you must sanitize and structure any data written to logs. Do not log raw tokens or uncontrolled claims. Instead, log only necessary metadata, and ensure that newlines and other control characters are either removed or encoded. Below are concrete code examples demonstrating safe practices in Go using the Fiber framework and a standard JWT library.

1. Avoid logging raw tokens or claims directly. Instead, log sanitized identifiers and use structured logging with explicit fields.

// Example: safe structured logging for a JWT-authenticated request in Fiber
package main

import (
	"log"
	"strings"

	"github.com/gofiber/fiber/v2"
	"github.com/golang-jwt/jwt/v5"
)

func sanitizeLogInput(s string) string {
	// Replace newlines and carriage returns; keep only safe characters for logs
	return strings.ReplaceAll(strings.ReplaceAll(s, "\n", "\\n"), "\r", "\\r")
}

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

	app.Get("/profile", func(c *fiber.Ctx) error {
		auth := c.Get("Authorization")
		if auth == "" {
			return c.SendStatus(fiber.StatusUnauthorized)
		}
		// Expect "Bearer <token>"
		tokenString := strings.TrimPrefix(auth, "Bearer ")
		// Parse and validate the token (example uses jwt.Parse; adapt to your verifier)
		token, _, err := new(jwt.Parser).ParseUnverified(tokenString, jwt.MapClaims{})
		if err != nil {
			// Log safely: do not include raw token
			log.Printf("token_parse_error: %s, token_prefix: %s", sanitizeLogInput(err.Error()), sanitizeLogInput(tokenString[:min(len(tokenString), 8)]))
			return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid_token"})
		}
		claims, ok := token.Claims.(jwt.MapClaims)
		if !ok || !token.Valid {
			log.Printf("token_invalid: subject=%s", sanitizeLogInput("unknown"))
			return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "invalid_claims"})
		}
		// Log only safe, structured fields
		log.Printf("auth_success: subject=%s, issuer=%s",
			sanitizeLogInput(claims["sub"].(string)),
			sanitizeLogInput(claims["iss"].(string)))
		return c.JSON(fiber.Map{"subject": claims["sub"]})
	})

	app.Listen(":8080")
}

func min(a, b int) int {
	if a < b {
		return a
	}
	return b
}

2. Configure your logger to escape or drop control characters globally. If you use a structured logger, ensure text fields are properly escaped and multi-line messages are not created. For example, avoid formatting log lines with raw user input that may contain newline characters.

3. Ensure that any JWT validation error paths do not echo back the token or its unescaped payload. In the example above, token substrings are truncated and sanitized before inclusion in logs, and error messages are passed through sanitizeLogInput to remove or escape newline and carriage-return characters.

These steps prevent newline-based injection that could forge log entries or hide follow-on attacks, while still allowing useful audit records for JWT authentication events.