Log Injection in Axum with Cockroachdb

Log injection occurs when untrusted input is written directly into application logs without proper sanitization or formatting control. In an Axum application using Cockroachdb as the backend datastore, the risk arises at the intersection of HTTP request handling, structured logging practices, and SQL-driven data flows. Axum does not inherently sanitize data that developers embed in log statements, and Cockroachdb, while robust in consistency and SQL compliance, does not enforce log formatting or escaping.

Consider a typical request flow: an Axum handler receives user-controlled parameters such as user_id or search_term, passes them to a Cockroachdb query, and then logs contextual information about the request. If a developer writes logs like info!("querying for user: {user_id}") and user_id contains newline characters or structured log delimiters (e.g., \n or JSON-like fragments), the resulting log stream can be corrupted or misleading. Newlines can split single logical log entries into multiple lines, breaking log aggregation tools that rely on line-oriented parsing. An attacker could supply input such as 123\n{"level":"ERROR"} " to inject fabricated log lines that appear authoritative.

In a Cockroachdb-driven Axum service, this often surfaces in endpoints that log query parameters before passing them to SQL. For example, logging the exact SQL string or placeholder values without escaping can create ambiguity between application logs and database telemetry. Because Cockroachdb supports structured data types (e.g., JSONB), developers might log query results directly. If a result field contains user-controlled strings with carriage returns or control characters, and those fields are written into logs without sanitization, the log integrity is compromised. This can obscure real errors, enable log forging for social engineering, or bypass log-based monitoring rules that assume one line equals one event.

Additionally, Axum’s middleware and tracing integrations may propagate request-scoped identifiers into logs. When these identifiers are derived from or influenced by database values from Cockroachdb, special characters in the data can distort trace or span representations in observability platforms. The vulnerability is not in Axum or Cockroachdb per se, but in the developer practice of directly interpolating uncontrolled data into log outputs. The risk is amplified when logs are centralized and used for security monitoring, as injected content may be misinterpreted as legitimate events or hide genuine anomalies.

Remediation focuses on strict input validation, structured logging with safe serialization, and isolating log content from database-driven values. In Axum, implement logging guards before data reaches the logging layer and ensure all data written to logs is sanitized and escaped.

First, validate and normalize inputs before they are used in both database queries and log statements. For string identifiers that will be logged, reject or sanitize newlines and control characters at the handler level. For example:

use axum::{routing::get, Router};
use std::net::SocketAddr;

async fn user_handler(user_id: String) -> String {
    // Reject or sanitize dangerous characters early
    if user_id.contains('\n') || user_id.contains('\r') {
        return String::from("invalid user_id");
    }
    // Proceed to database interaction
    format!("user-{}", user_id)
}

#[tokio::main]
async fn main() -> SocketAddr {
    let app = Router::new().route("/users/:user_id", get(|user_id: String| async move {
        user_handler(user_id).await
    }));
    axum::Server::bind(&"0.0.0.0:3000".parse().unwrap())
        .serve(app.into_make_service())
        .await
        .unwrap()
}

Second, use structured logging with a library that escapes special characters automatically. For JSON-formatted logs, ensure string values are properly encoded. If you log database query parameters, serialize them via a safe formatter rather than string interpolation:

use tracing::info;

fn log_query_params(user_id: &str) {
    // Safe: structured logging ensures proper escaping
    info!(user_id = %user_id, "query_user");
}

Third, when retrieving data from Cockroachdb, avoid logging raw result fields that may contain user-controlled content. If you must log such data, sanitize it explicitly:

use cockroachdb_rs::Connection;

async fn fetch_and_log(conn: &Connection, user_id: &str) {
    let row = conn.query_one("SELECT name FROM users WHERE id = $1", &[&user_id]).await.unwrap();
    let name: String = row.get(0);
    // Sanitize before logging: replace newlines and control chars
    let safe_name = name.replace(|c: char| c == '\n' || c == '\r', "_");
    tracing::info!(user_name = %safe_name, "fetched_user");
}

Finally, leverage Axum extractors and middleware to enforce consistent logging hygiene across endpoints. Custom middleware can inspect and redact sensitive or problematic characters before logs are emitted, ensuring that database values and request parameters are uniformly treated.