Log Injection in Axum with Mutual Tls

Log Injection occurs when an attacker can control or influence data that is written into application or TLS-layer logs. In Axum applications that terminate Mutual TLS (mTLS), the combination of client certificate metadata and unchecked request attributes can create conditions where log entries become untrustworthy.

Mutual TLS provides strong transport-layer identity: the server requests and validates a client certificate, and the client validates the server certificate. When mTLS is enabled in Axum (typically via a reverse proxy or Rustls/Tokio-Rustls setup), the framework can access certificate fields such as subject distinguished name (DN), serial number, and SANs. If these values are interpolated directly into log messages without validation or sanitization, an attacker who can present a malicious certificate can inject structured or unstructured text into logs.

For example, an attacker may control the Common Name (CN) or organizational attributes in their certificate and supply crafted values like "injected_log' OR '1'='1 into a certificate field. If the logging code concatenates these fields into a human-readable message, the log entry may be corrupted or may be used to obscure true events when reviewed later. In distributed or security-critical environments, corrupted logs can reduce forensic accuracy and delay incident response. This becomes especially risky when logs are centralized and used for alerting or compliance reporting.

Additionally, mTLS setups often include rich metadata such as issuer, validity timestamps, and extended key usage. If Axum handlers or middleware log this metadata verbatim—especially in structured formats like JSON—malformed or overly long values can distort log parsers or SIEM ingestion. While mTLS ensures the identity of the peer, it does not guarantee that the identity information is safe for logging; validation and canonicalization remain the application’s responsibility.

In the context of middleBrick’s checks, Log Injection would appear under Input Validation and Data Exposure categories when scanning an Axum endpoint with mTLS. The scanner inspects whether certificate-derived fields are sanitized before being written to logs and whether structured logs preserve integrity. Remediation focuses on strict schema validation, safe serialization, and avoiding direct string interpolation of identity metadata.

Secure logging in Axum with mTLS requires explicit handling of certificate data before it reaches any logging statement. Instead of using the raw certificate fields in log messages, normalize and validate them, and structure logs in a way that preserves machine-readability without enabling injection.

Below is a concrete, working example of an Axum middleware that extracts certificate information safely and logs it using a controlled, structured approach. The example uses axum, tower-http, and serde_json to produce sanitized JSON logs.

use axum::{async_trait, extract::FromRequestParts, http::request::Parts, middleware::Next, response::Response};
use serde_json::json;
use std::collections::HashMap;
use tracing::{info, Instrument};

/// A safe extractor for mTLS identity metadata.
pub struct MtlsIdentity {
    pub subject_hash: String, // e.g., SHA-256 fingerprint, not raw DN
    pub issuer_hash: String,
    pub not_after: String,    // ISO-8601, validated
}

#[async_trait]
impl FromRequestParts for MtlsIdentity
where
    S: Send + Sync,
{
    type Rejection = ();

    async fn from_request_parts(parts: &mut Parts, _state: &S) -> Result {
        // In a real deployment, the proxy or Rustls layer populates extensions.
        // Here we simulate extraction with safe defaults and validation.
        let cert_fingerprint = parts
            .extensions
            .get::()
            .map(|s| sanitize_cert_string(s))
            .unwrap_or_else(|| "unknown".to_string());

        let issuer_fingerprint = parts
            .extensions
            .get::()
            .map(|s| sanitize_cert_string(s))
            .unwrap_or_else(|| "unknown".to_string());

        let not_after = parts
            .extensions
            .get::()
            .cloned()
            .unwrap_or_else(|| "unknown".to_string());

        Ok(MtlsIdentity {
            subject_hash: cert_fingerprint,
            issuer_hash: issuer_fingerprint,
            not_after,
        })
    }
}

/// Normalize certificate strings to prevent log injection.
fn sanitize_cert_string(value: &str) -> String {
    // Remove control chars, trim, and limit length.
    let trimmed = value.trim();
    let no_newlines = trimmed.replace(['\n', '\r'], " ");
    // Truncate to a safe length for logs.
    if no_newlines.len() > 256 {
        no_newlines[..256].to_string()
    } else {
        no_newlines
    }
}

/// Example handler that uses the safe identity.
async fn handler(identity: MtlsIdentity) -> String {
    // Structured logging with controlled fields.
    info!(
        "mtls_request"),
        {
            "subject_hash": identity.subject_hash.as_str(),
            "issuer_hash": identity.issuer_hash.as_str(),
            "not_after": identity.not_after.as_str(),
        }
    );
    format!("OK")
}

/// Build your Axum app with mTLS extraction and safe logging.
fn build_app() -> axum::Router {
    axum::Router::new()
        .route("/", axum::routing::get(handler))
        .layer(axum::middleware::from_fn(|axum::extract::RequestParts { headers, extensions, .. }, next| async move {
            // In production, certificate extraction would happen in the acceptor / proxy.
            // For this example we simulate placing sanitized values into extensions.
            extensions.insert("cert_fingerprint".to_string());
            extensions.insert("issuer_fingerprint".to_string());
            extensions.insert("2026-01-01T00:00:00Z".to_string());
            next.run().await
        }))
}