Log Injection in Actix with Basic Auth

Log injection occurs when untrusted input from a client is written directly into application or system logs without validation or sanitization. In Actix web applications that use HTTP Basic Authentication, this risk is heightened because credentials are often logged for auditing, debugging, or security monitoring. If an attacker can control any part of the request that is logged—such as the username or password extracted from the Authorization header—they can inject newline characters or other control sequences that corrupt log entries, forge log context, or obscure related malicious activity.

With Basic Auth, the client sends credentials as a base64-encoded string in the Authorization header (e.g., Authorization: Basic dXNlcjpwYXNz). Decoded, this becomes user:password. If the application logs the decoded username or password verbatim—perhaps to track authentication attempts or failed logins—an attacker can supply a username containing a newline (%0A or \n) or other crafted payload. Because log entries are often structured line-by-line, a newline in the username can split one logical log entry into multiple lines, enabling log forging, log injection, or log poisoning. This can complicate log analysis, bypass log-based monitoring rules, or create the appearance of legitimate activity when, in fact, it is malicious.

Even though Actix does not log credentials by default, developers may add custom logging for authentication events. If such logging concatenates user-controlled data directly into log strings without escaping or structured formatting, the application becomes vulnerable. For example, logging format!("User authenticated: {}", username) where username contains newlines or carriage returns can distort log integrity. In a security context, this may reduce trust in log data, hinder incident response, and complicate compliance reporting. Because Log Injection does not necessarily cause direct application compromise, it is often classified with medium severity; however, in regulated environments it can contribute to audit failures or enable secondary attacks that rely on manipulated log evidence.

middleBrick detects Log Injection risks by analyzing how request data is handled and whether untrusted input reaches log sinks. In scans that include Basic Auth endpoints, the tool checks whether decoded credentials or other user-controlled headers are incorporated into logging logic without sanitization. Findings include severity ratings and remediation guidance mapped to frameworks such as OWASP API Top 10 and common logging best practices.

To prevent log injection in Actix when using Basic Authentication, you must ensure that any user-controlled data written to logs is sanitized, escaped, or structured so that control characters cannot alter log formatting. The most effective approach is to avoid logging credentials entirely. If logging is required for operational or security auditing, use structured logging with explicit field separation and disallow raw newline characters in logged values.

Below are concrete Actix examples that demonstrate safe handling of Basic Auth credentials. The first example shows a vulnerable pattern where credentials are decoded and logged directly:

use actix_web::{web, App, HttpResponse, HttpServer, Responder};
use base64::decode;

async fn login_basic(auth_header: web::Header<&str>) -> impl Responder {
    if let Some(auth_value) = auth_header.strip_prefix("Basic ") {
        if let Ok(decoded) = decode(auth_value) {
            if let Ok(credentials) = String::from_utf8(decoded) {
                let parts: Vec<&str> = credentials.splitn(2, ':').collect();
                if parts.len() == 2 {
                    let username = parts[0];
                    let _password = parts[1];
                    // Vulnerable: logging user-controlled data directly
                    println!("Authenticated user: {}", username);
                    return HttpResponse::Ok().body("Logged in");
                }
            }
        }
    }
    HttpResponse::Unauthorized().body("Invalid auth")
}

In this example, if username contains a newline, the log line can be split or forged. To remediate, either avoid logging usernames or sanitize the input by removing or replacing control characters. The following safe version uses sanitization and structured logging fields:

use actix_web::{web, App, HttpResponse, HttpServer, Responder};
use base64::decode;

fn sanitize_log_value(value: &str) -> String {
    value.replace(['\n', '\r', '\t'], "_")
}

async fn login_basic_safe(auth_header: web::Header<&str>) -> impl Responder {
    if let Some(auth_value) = auth_header.strip_prefix("Basic ") {
        if let Ok(decoded) = decode(auth_value) {
            if let Ok(credentials) = String::from_utf8(decoded) {
                let parts: Vec<&str> = credentials.splitn(2, ':').collect();
                if parts.len() == 2 {
                    let username = sanitize_log_value(parts[0]);
                    // Safe: logging sanitized value, no raw newlines
                    println!("auth_event={{user={}, status=success}}", username);
                    return HttpResponse::Ok().body("Logged in");
                }
            }
        }
    }
    println!("auth_event={{user=unknown, status=failed}}");
    HttpResponse::Unauthorized().body("Invalid auth")
}

Additionally, consider using structured logging crates (e.g., tracing or log with JSON formatting) so that each field is typed and delimited by the logging framework, reducing the risk that injected characters affect record boundaries. With these changes, the application remains compatible with authentication workflows while eliminating a common vector for log injection.

middleBrick’s scans can validate whether endpoints using Basic Auth expose log injection risks by examining application behavior and logging patterns. The tool provides prioritized findings and remediation guidance, helping you address issues without implementing internal fixes or assuming automatic correction.