Log Injection in Chi with Api Keys

Log injection occurs when untrusted input is written directly into application or system logs without proper sanitization. In the Chi routing library for Clojure, developers often include contextual information such as API keys in access logs to correlate requests with accounts or debug issues. When an API key is logged verbatim and the value contains newline characters or other control characters, an attacker can craft a malicious API key that introduces additional log lines or alters the log structure. This can turn a diagnostic log stream into a source of confusion, obscuring the true sequence of events or enabling log forging where attacker-supplied content appears to originate from a legitimate key.

Chi applications frequently log request metadata, including path parameters, headers, and selected headers such as authorization tokens. If an API key is extracted from headers and logged without validation or escaping, an attacker can supply a key containing sequences like newline (\n) or carriage return (\r). These characters cause the logging backend to treat a single logical event as multiple entries, which can bypass log-based monitoring assumptions that each line corresponds to a single request. In distributed systems where logs are aggregated, such injected content may also interfere with parsing, leading to gaps in security analytics or false positives that dilute incident response.

The interaction between Chi and API keys becomes particularly risky when logs are used for security decisions or compliance evidence. For example, if a log line is expected to follow a strict format like timestamp api_key=... status=..., an injected newline followed by a crafted message can create a secondary log entry that appears to belong to the same request. This may facilitate evasion of detection rules or enable log injection-based attacks against downstream systems that consume those logs. Because API keys are high-value targets, ensuring they are safely handled in logs is essential to maintaining integrity and traceability.

Real-world patterns observed in frameworks like Chi include direct interpolation of headers into logging functions without normalization. Consider a route that logs the API key header to troubleshoot authentication issues. If the API key contains structured delimiters or newlines, the resulting log entry can break the expected format. Attackers can exploit this by embedding commands or references that, while harmless to Chi, can mislead operators or feed malicious content into log management platforms. Therefore, treating API keys as untrusted input even when they are used for diagnostics is critical to preventing log injection.

middleBrick identifies log injection risks related to API key handling during black-box scans, testing how unexpected characters in keys affect log integrity. By exercising endpoints with specially crafted API key values, the scanner highlights scenarios where logs may be corrupted or misleading. This supports secure development practices by emphasizing output encoding and structured logging, ensuring that sensitive identifiers do not compromise log reliability.

To remediate log injection when handling API keys in Chi, sanitize and normalize all values before they reach logging functions. Do not assume API keys are safe simply because they are treated as opaque strings. Instead, canonicalize the key by removing or encoding control characters, and use structured logging formats that separate fields unambiguously. Below are concrete examples demonstrating safe practices within a Chi handler.

First, define a small utility to clean an API key by stripping or replacing characters that can disrupt log parsing:

(ns myapp.log
  (:require [clojure.string :as str]))

(defn sanitize-api-key
  "Remove newline and carriage return characters from an API key to prevent log injection."
  [key]
  (-> key
      (str/replace #"[\n\r]" "")))

Next, use this utility in a Chi route that logs request details. By applying sanitize-api-key before including the key in log output, you ensure that no line breaks can be injected:

(ns myapp.routes
  (:require [compojure.core :refer [GET defroutes]]
            [ring.util.response :as resp]
            [myapp.log :refer [sanitize-api-key]]))

(defn handler [request]
  (let [api-key (get-in request [:headers "x-api-key"])
        safe-key (sanitize-api-key (or api-key ""))]
    (println (str "request path=" (:uri request) " api_key=" safe-key " status=ok"))
    (resp/ok "OK")))

(defroutes app-routes
  (GET "/*" request (handler request)))

For more robust logging, prefer structured data formats such as EDN or JSON, which avoid delimiter ambiguity. In Chi, you can output JSON logs where each field is properly escaped, preventing injected newlines from breaking the structure:

(ns myapp.json-logging
  (:require [cheshire.core :as json]
            [ring.util.response :as resp]))

(defn json-log
  [method uri api-key status]
  (let [data {:timestamp (java.time.Instant/now)
              :method method
              :uri uri
              :api_key (when api-key (str/replace api-key #"[\n\r]" ""))
              :status status}]
    (println (json/generate-string data))))

(defn handler [request]
  (let [api-key (get-in request [:headers "x-api-key"])
        status "ok"]
    (json-log (:request-method request) (:uri request) api-key status)
    (resp/ok "OK")))

Additionally, enforce validation at the boundary by rejecting obviously malformed keys early. If your API key format is well-defined (e.g., hexadecimal strings of fixed length), use a regular expression check and return a 400 Bad Request for invalid inputs, which prevents problematic keys from entering your logging pipeline:

(ns myapp.validation
  (:require [ring.util.response :as resp]))

(defn valid-api-key?
  "Return true if the key matches the expected pattern."
  [key]
  (boolean (and key (re-matches #"[A-F0-9]{32}" key))))

(defn handler [request]
  (let [api-key (get-in request [:headers "x-api-key"])]
    (if-not (valid-api-key? api-key)
      (resp/bad-request "Invalid API key format")
      (let [safe-key (str/replace api-key #"[\n\r]" "")]
        (println (str "api_key=" safe-key " status=valid"))
        (resp/ok "OK")))))

By combining sanitization, structured logging, and strict validation, you mitigate log injection risks associated with API keys in Chi applications while preserving useful diagnostic context.