Format String in Chi with Api Keys

In Chi, a web framework for OCaml, format string vulnerabilities arise when unchecked external input is passed directly to formatting functions such as Printf.kprintf or Format.kprintf. When API keys are handled as user-controlled values and interpolated into log messages, error responses, or debug output, an attacker can supply format specifiers (e.g., %s, %x, %n) that cause reading from or writing to memory. This can leak an API key or corrupt data, undermining the confidentiality and integrity of the key.

Chi encourages strongly typed request handling, but developers sometimes construct log lines or error messages by concatenating strings or using format builders with unchecked user input. For example, passing an API key obtained from a header directly into a format string allows an attacker to manipulate the formatting behavior. Consider a route that logs an API key for debugging: if the logging call uses a format that includes a user-supplied key as a format parameter, the key can be interpreted as a format directive. This can expose the key in logs or trigger information disclosure through extra arguments read from the stack.

Chi routes typically pattern-match on path and query parameters; API keys are often extracted from headers or cookies. If a developer writes code like Printf.sprintf "Key: %s" key where key comes from an untrusted source, and an attacker provides key=AAAA%20%s, the resulting string may cause additional memory reads. Similarly, using Format.asprintf with unchecked concatenation can yield the same issue. Even when keys are validated for format correctness, logging or error formatting that does not treat the key as a plain value creates an opening for format string bugs.

Real-world impact includes leaking API keys that grant access to backend services, enabling further attacks such as privilege escalation or data exfiltration. In a microservice architecture, a compromised API key can move laterally across internal endpoints. Because Chi applications often integrate with external systems via keys for authentication and authorization, format string issues here can have broader consequences than in isolated services.

The vulnerability also intersects with other security checks middleBrick performs, such as Data Exposure and Input Validation. Even when API keys are stored securely, improper formatting can inadvertently expose them in responses or logs. Developers must ensure that any user-influenced data is passed as arguments, never as format strings, and that keys are handled as opaque values.

To remediate format string risks when handling API keys in Chi, treat keys as opaque data and never use them as format arguments. Instead, use constant-format logging and strict string construction. Below are concrete, safe patterns for OCaml with Chi routes.

Safe logging with API keys

Use a logging library that does not interpret format specifiers from external data. For example, with Logs, pass the key as a metadata field rather than interpolating it into a format string:

open Chi
open Logs

let key_logger key =
  Logs.info (fun m -> m "API key received" % metadata "api_key" (Logs.metadata_of_string key))

let route =
  get @@ fun _ ->
    let key = Header.get "X-API-Key" request in
    key_logger key;
      Response.make ~status:`Ok ()

Here, the key is never part of a format string; it is attached as structured metadata, avoiding any risk of format injection while still enabling observability.

Safe error responses

When returning errors that involve API keys, construct messages with constant formats:

let respond_bad_key request =
  let key = Header.get "X-API-Key" request in
  let safe_key = if String.length key > 8 then String.sub key 0 4 ^ "****" else "****" in
  Server.respond_string ~status:`Bad_request
    ("Invalid key: " ^ safe_key)

The key is truncated and masked before inclusion in a plain string, and no format specifiers from the key are interpreted.

Validation without formatting

Validate the key format using regular expressions or length checks, and reject invalid keys with a constant response:

let is_valid_key key =
  try
    let _ = Base64.decode_exn key in
    true
  with Invalid_argument _ -> false

let handler request =
  match Header.get_cow request "X-API-Key" with
  | None -> Server.respond_string ~status:`Unauthorized "Missing key"
  | Some key ->
    if is_valid_key key then
      Server.respond_string ~status:`Ok "Authenticated"
    else
      Server.respond_string ~status:`Unauthorized "Invalid key format"

This approach avoids any dynamic format construction from the key itself and uses fixed strings for responses.

Dependency and configuration hygiene

Ensure that any third-party libraries used for logging or configuration do not inadvertently treat API keys as format strings. Prefer structured configuration and typed headers to reduce risk.