Insufficient Logging in Actix with Api Keys

Insufficient logging in Actix applications that rely on API keys for authentication creates a blind spot that weakens detection, investigation, and compliance. When API keys are validated but events are not recorded with sufficient context, you lose the ability to trace who used which key, when, and with what outcome. This combination means that abuse, credential leakage, or misuse can persist without visibility.

In Actix, a typical API key check might be implemented as a guard or extractor that validates a key before allowing access to a handler. If the application only returns HTTP 401 or 200 without writing structured logs, an attacker can probe keys repeatedly, and an operator has no timestamped evidence. MiddleBrick’s checks for Authentication and BOLA/IDOR highlight scenarios where authentication decisions are made without corresponding audit trails, which maps to gaps in detectability.

Real-world impact examples include:

• An exposed API key in a public repository leads to unauthorized usage, but without request logs you cannot determine the scope or data accessed.
• A stolen key used to scrape or modify resources leaves no per-key audit record, complicating incident response and forensics.
• Compliance frameworks such as PCI-DSS and SOC2 require audit trails for access to protected resources; insufficient logging in Actix with API keys can cause failed audits.

Effective logging must capture enough context to correlate requests with keys without logging the keys themselves. This includes timestamps, client IP, request path, HTTP method, outcome (success/failure), and a request identifier. MiddleBrick’s Data Exposure and Inventory Management checks evaluate whether sensitive data is logged and whether asset-level tracking exists, which is especially important when API keys are involved.

Additionally, logging should be structured (e.g., JSON) to enable automated analysis and alerting. Without structured logs, detecting patterns such as credential stuffing or anomalous usage becomes manual and error-prone. The LLM/AI Security checks in MiddleBrick emphasize that output and system information must not inadvertently expose keys; similarly, application logs must not store keys in plaintext while still providing actionable auditability.

Remediation focuses on structured, context-rich logging around API key validation while ensuring keys are never logged in plaintext. Below are concrete Actix examples that demonstrate secure validation and logging patterns.

Example 1: Logging key usage on successful validation

Use a guard or extractor to validate the key, then emit structured logs on success. This ensures you record successful authenticated requests without exposing the key.

use actix_web::{web, HttpRequest, HttpResponse, Result};
use log::{info, error};
use serde_json::json;

fn validate_api_key(req: &HttpRequest, provided: &str) -> bool {
    // Replace with secure lookup (e.g., constant-time compare against a store)
    let valid_keys = vec!["s3cr3tk3y123"]; // example only
    valid_keys.contains(&provided)
}

async fn handler_with_logging(req: HttpRequest, body: web::Json) -> Result {
    let api_key = match req.headers().get("X-API-Key") {
        Some(v) => v.to_str().unwrap_or(""),
        None => {
            warn_no_key(&req);
            return Ok(HttpResponse::Unauthorized().finish());
        }
    };

    if validate_api_key(&req, api_key) {
        info_log_successful_key_use(&req, api_key);
        Ok(HttpResponse::Ok().json(json!({ "status": "ok" })))
    } else {
        error_log_invalid_key(&req, api_key);
        Ok(HttpResponse::Unauthorized().finish())
    }
}

fn warn_no_key(req: &HttpRequest) {
    let client_ip = req.connection_info().realip_remote_addr().unwrap_or("unknown");
    error!(target: "api_key_audit",
        event = "missing_api_key",
        method = %req.method(),
        path = %req.path(),
        peer_addr = %client_ip,
        message = "API key header missing"
    );
}

fn info_log_successful_key_use(req: &HttpRequest, key_id: &str) {
    let client_ip = req.connection_info().realip_remote_addr().unwrap_or("unknown");
    info!(target: "api_key_audit",
        event = "key_used",
        key_id = %key_id,
        method = %req.method(),
        path = %req.path(),
        peer_addr = %client_ip,
        status = 200
    );
}

fn error_log_invalid_key(req: &HttpRequest, key_id: &str) {
    let client_ip = req.connection_info().realip_remote_addr().unwrap_or("unknown");
    warn!(target: "api_key_audit",
        event = "invalid_key",
        key_id = %key_id,
        method = %req.method(),
        path = %req.path(),
        peer_addr = %client_ip
    );
}

Example 2: Centralized logging middleware in Actix

Adding a middleware ensures every request is logged with consistent context, including API key usage when present.

use actix_web::{dev::ServiceRequest, dev::ServiceResponse, Error, middleware::Middleware};
use actix_web::body::BoxBody;
use log::info;

pub struct ApiKeyAuditMiddleware;

impl Middleware for ApiKeyAuditMiddleware {
    fn start(&self, req: &ServiceRequest) -> Result<(), Error> {
        let client_ip = req.connection_info().realip_remote_addr().unwrap_or("unknown").to_string();
        let key = req.headers().get("X-API-Key")
            .map(|v| v.to_str().unwrap_or("invalid").to_string())
            .unwrap_or_else(|| "none".to_string());
        // Log presence of key but not its value
        let key_present = key != "none" && key != "invalid";
        info!(
            target: "api_key_audit",
            event = "request_start",
            method = %req.method(),
            path = %req.path(),
            key_present = %key_present,
            peer_addr = %client_ip
        );
        Ok(())
    }

    fn response(&self, req: &ServiceRequest, resp: ServiceResponse) -> Result<(), Error> {
        let status = resp.status().as_u16();
        let key = req.headers().get("X-API-Key")
            .map(|v| v.to_str().unwrap_or("invalid").to_string())
            .unwrap_or_else(|| "none".to_string());
        let key_present = key != "none" && key != "invalid";
        info!(
            target: "api_key_audit",
            event = "request_complete",
            method = %req.method(),
            path = %req.path(),
            key_present = %key_present,
            status = %status
        );
        Ok(())
    }
}