Email Injection in Fiber with Api Keys

Email Injection in a Fiber-based API typically occurs when user-controlled input is concatenated into email-related operations such as headers, recipients, or message bodies without validation. When an API key mechanism is implemented naively, the same unsafe patterns can expose key material or enable injection through email channels.

Consider a Fiber handler that builds an email using user-supplied data and an API key for internal routing or identification:

// Unsafe: concatenating user input into email headers
app.Post("/notify", func(c *fiber.Ctx) error {
    userEmail := c.FormValue("email")
    apiKey := c.Get("X-API-Key")
    subject := "Notification: " + c.FormValue("subject")
    body := "User: " + userEmail + "\nMessage: " + c.FormValue("message")
    // Simulated email send; in practice this would use an email provider client.
    // If userEmail or subject contains newline characters, headers can be injected.
    // If apiKey is reflected in logs or error messages sent via email, key leakage occurs.
    return c.SendString("Queued: to=" + userEmail + " subject=" + subject)
})

In this pattern, newline characters (\r\n) in userEmail or subject can inject additional headers (e.g., Cc:, Bcc:, or custom headers), leading to Email Injection. An attacker could forge recipients or inject SMTP commands if the downstream email library is vulnerable. Because the API key is used for authorization but also appears in logging or error contexts tied to the email operation, it may be inadvertently exposed in injected email content or logs, creating a data exposure path.

The LLM/AI Security checks in middleBrick specifically test for output channels that could leak API keys and for input vectors that enable injection. Even in unauthenticated scans, newline-based injection and key leakage through error strings are detectable. The scan will flag findings such as CWE-943 (Improper Control of Message Injection) and CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor), with remediation guidance tied to secure handling of API keys and strict input validation.

Secure remediation focuses on two aspects: preventing email injection by strictly validating and encoding user input, and protecting API keys from exposure through logs, errors, or email content.

1) Validate and encode email and header inputs. Use a allowlist for email addresses and reject or sanitize newlines in headers:

// Safe: validate email and reject newlines in subject
import "regexp"
import "strings"

var emailRegex = regexp.MustCompile(`^[a-zA-Z0-9.!#$%&'*+/=?^_` + "`" + `{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])*)$`)

app.Post("/notify", func(c *fiber.Ctx) error {
    userEmail := strings.TrimSpace(c.FormValue("email"))
    subject := c.FormValue("subject")
    message := c.FormValue("message")

    if !emailRegex.MatchString(userEmail) {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid email"})
    }
    if strings.ContainsAny(subject, "\r\n") {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "subject contains invalid characters"})
    }
    // Safe: use parameterized email client methods; avoid concatenating headers.
    return c.SendString("Queued: to=" + userEmail)
})

2) Handle API keys securely: never derive keys from user input, avoid logging them, and do not include them in email content. Store keys in environment variables and reference them via configuration. When calling external services, inject the key via secure headers without exposing it in logs:

// Secure: load API key from environment and use it as a bearer token
apiKey := os.Getenv("EMAIL_SERVICE_API_KEY")
if apiKey == "" {
    return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "server configuration error"})
}

// Example: attaching key via Authorization header when using an HTTP-based email provider
req, err := http.NewRequest("POST", emailServiceURL, bytes.NewBuffer(payload))
if err != nil {
    return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "request creation failed"})
}
req.Header.Set("Authorization", "Bearer " + apiKey)
req.Header.Set("Content-Type", "application/json")
req.Header.Set("X-Request-ID", c.Request().Header.Get("X-Request-ID")) // propagate traceability without echoing user input

client := &http.Client{}
resp, err := client.Do(req)
if err != nil {
    return c.Status(fiber.StatusBadGateway).JSON(fiber.Map{"error": "email service unavailable"})
}
defer resp.Body.Close()

return c.SendStatus(fiber.StatusAccepted)

These steps align with middleBrick findings by ensuring input validation (BOLA/IDOR and Input Validation checks) and protecting key material (Data Exposure and Encryption checks). The scanner will map these practices to relevant compliance frameworks and provide prioritized remediation steps.