Log Injection in Fiber with Dynamodb

Log injection occurs when untrusted input is written directly into log entries without sanitization or formatting, allowing an attacker to forge log lines, obscure real events, or inject additional metadata. In a Go Fiber application that stores or references data in DynamoDB, the combination of structured logging expectations, the DynamoDB SDK’s request/response handling, and Fiber’s flexible middleware chain can expose log injection risks.

Consider a Fiber handler that logs a request after fetching or storing an item in DynamoDB:

app.Get("/item/:id", func(c *fiber.Ctx) error {
    id := c.Params("id")
    out, err := svc.GetItem(context.TODO(), &dynamodb.GetItemInput{
        TableName: aws.String("Items"),
        Key: map[string]types.AttributeValue{
            "id": &types.ScalarAttributeValue{V: id},
        },
    })
    if err != nil {
        c.Logger().Errorf("dynamodb get error: %v", err)
        return c.SendStatus(fiber.StatusInternalServerError)
    }
    c.Logger().Infof("fetched item: %v", out.Item)
    return c.JSON(out.Item)
})

If the id path parameter or any field inside out.Item contains newline characters or structured log-like text (e.g., a user-supplied string with embedded CR/LF), the log line produced by c.Logger().Infof can be corrupted. An attacker could supply an id such as 123\nX-Forwarded-For: 10.0.0.1, causing the log to appear as two separate entries and potentially bypass log-based monitoring rules. Similarly, DynamoDB error responses or conditional check failures may include user-controlled values; logging them verbatim with c.Logger().Errorf("dynamodb get error: %v", err) can allow injection of additional fields or newlines into the log stream.

In a broader architecture where logs are parsed by SIEM tools or monitoring agents that rely on line-oriented ingestion, injected newlines or structured fragments (like key-value pairs) can break parsing, create false positives, or hide genuine events. The DynamoDB SDK itself does not introduce injection, but its output—especially error messages and attribute values—must be treated as untrusted input when constructing log messages. Fiber’s logger is convenient but does not sanitize or isolate user data; therefore, logging raw SDK outputs or uncontrolled identifiers directly enables log injection in this specific stack.

To prevent log injection, ensure that any data derived from DynamoDB (including IDs, attribute values, and error details) is sanitized before being written to logs. Avoid directly interpolating user-controlled values or SDK outputs into log statements. Instead, use structured logging with explicit field separation and escape newlines or control characters.

Example of a safe approach using explicit field logging and sanitization:

import (
    "strings"
    "github.com/gofiber/fiber/v2"
    "github.com/aws/aws-sdk-go-v2/service/dynamodb"
    "github.com/aws/aws-sdk-go-v2/aws"
)

func sanitizeLog(s string) string {
    // Replace newlines and carriage returns to prevent line splitting
    s = strings.ReplaceAll(s, "\r", "\\r")
    s = strings.ReplaceAll(s, "\n", "\\n")
    return s
}

app.Get("/item/:id", func(c *fiber.Ctx) error {
    id := c.Params("id")
    safeID := sanitizeLog(id)
    out, err := svc.GetItem(context.TODO(), &dynamodb.GetItemInput{
        TableName: aws.String("Items"),
        Key: map[string]types.AttributeValue{
            "id": &types.ScalarAttributeValue{V: id},
        },
    })
    if err != nil {
        // Log error details without injecting user values into the message format
        c.Logger().Errorf("dynamodb get error: %v", sanitizeLog(err.Error()))
        return c.SendStatus(fiber.StatusInternalServerError)
    }
    // Log a structured message with explicit fields
    c.Logger().Infof("fetched item key=id value=%s", safeID)
    return c.JSON(out.Item)
})

When logging DynamoDB attribute values that may contain newlines or special characters, apply sanitizeLog to each value before inclusion. For structured logging, prefer key=value formatting so parsers can tolerate spaces and equal signs within values. Avoid logging the entire out.Item map via default formatting; instead, explicitly select and sanitize fields you need in logs. This prevents hidden newlines inside nested attribute values from corrupting log lines.

Additionally, ensure that any log metadata derived from request context (headers, host) is similarly sanitized. Combining these practices across Fiber middleware and DynamoDB integration points reduces the risk of log injection while preserving useful diagnostic information.