HIGH insufficient loggingaxumapi keys

Insufficient Logging in Axum with Api Keys

Insufficient Logging in Axum with Api Keys — how this specific combination creates or exposes the vulnerability

Insufficient logging in Axum applications that use API keys creates a gap in observability and forensic readiness. When API keys are validated but events are not recorded in detail, security teams lose visibility into authentication successes and failures. This lack of logging means brute-force attempts, credential reuse, or leaked keys may go unnoticed, allowing an attacker to operate without detection.

In Axum, the combination of API key handling and missing structured logs amplifies risk. Axum routes typically extract keys from headers (e.g., Authorization: ApiKey <token>) and validate them against a store or constant. If the application does not log key identifiers (e.g., key ID or hash), timestamps, client IPs, request paths, and outcomes, investigations after an incident become speculative. Attackers can probe endpoints with many keys, and without logs, defenders cannot identify patterns like credential stuffing or geographic anomalies.

Middleware is a natural place to enforce logging, but if the middleware only validates keys and does not emit structured events, the attack surface remains opaque. For example, an Axum app might use a tower layer to check keys and return early on rejection, yet skip logging rejected attempts. This omission conflicts with security best practices that require audit trails for authentication events, including failures, to support detection and response. Without logs, organizations cannot map API key usage to users or services, complicating compliance evidence for frameworks such as OWASP API Top 10 and SOC2.

Additionally, insufficient logging can intersect with data exposure risks. If an API key is logged in plaintext in environments with broader log access, it becomes a secret in logs, potentially exposed to unauthorized viewers. Conversely, if logs are too sparse (e.g., omitting key identifiers), correlation across services becomes difficult, reducing the effectiveness of monitoring tools. Balanced logging that records non-sensitive metadata—such as key ID prefix, request outcome, and rate-limiting decisions—helps maintain security telemetry without compromising secret safety.

Api Keys-Specific Remediation in Axum — concrete code fixes

Remediation focuses on structured, actionable logging while preserving security. In Axum, implement logging in the key validation layer (e.g., middleware or extractor) to record relevant events without exposing secrets. Use tracing or logging crates such as tracing to emit structured events that include severity, timestamps, request metadata, and outcomes.

Example: a reusable API key extractor with logging on success and failure.

use axum::async_trait;
use axum::extract::{FromRequest, Request};
use axum::http::StatusCode;
use axum::response::IntoResponse;
use std::fmt;
use tracing::{info, warn};

#[derive(Debug, Clone)]
pub struct ApiKey(String);

#[derive(Debug)]
pub enum KeyError {
    Missing,
    Invalid,
}

impl fmt::Display for KeyError {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        match self {
            KeyError::Missing => write!(f, "missing api key"),
            KeyError::Invalid => write!(f, "invalid api key"),
        }
    }
}

impl IntoResponse for KeyError {
    fn into_response(self) -> (StatusCode, String) {
        let (status, message) = match self {
            KeyError::Missing => (StatusCode::UNAUTHORIZED, "Missing API key".to_string()),
            KeyError::Invalid => (StatusCode::FORBIDDEN, "Invalid API key".to_string()),
        };
        (status, message).into_response()
    }
}

#[async_trait]
trait KeyResolver {
    async fn resolve(&self, key: &str) -> bool;
}

#[async_trait]
impl KeyResolver for F
where
    F: Fn(&str) -> Fut + Send + Sync,
    Fut: std::future::Future<Output = bool> + Send + Sync,
{
    async fn resolve(&self, key: &str) -> bool {
        self(key).await
    }
}

pub fn with_api_key<R, Resolver>(resolver: Resolver) -> impl Fn(Request, Next<Body>) -> Pin<Box<dyn Future<Output = Response<Body>> + Send + Sync + '_>>
where
    R: KeyResolver + Clone + Send + Sync + 'static,
    Resolver: Fn() -> R + Clone + Send + Sync + 'static,
{
    move |req: Request, next: Next<Body>| {
        let resolver = resolver.clone();
        async move {
            let key = match req.headers().get("ApiKey") {
                Some(h) => h.to_str().unwrap_or(""),
                None => {
                    warn!(event = "auth_failure", reason = "missing_key", path = %req.uri().path(), method = %req.method().as_str(), "API key missing");
                    return (StatusCode::UNAUTHORIZED, "Missing API key").into_response();
                }
            };
            let resolver = resolver();
            let valid = resolver.resolve(key).await;
            if valid {
                info!(event = "auth_success", key_id = %key[..4], path = %req.uri().path(), method = %req.method().as_str(), "API key accepted");
                next.run(req).await
            } else {
                warn!(event = "auth_failure", key_id = %key[..4], path = %req.uri().path(), method = %req.method().as_str(), "Invalid API key");
                (StatusCode::FORBIDDEN, "Invalid API key").into_response()
            }
        }
    }
}

This pattern logs key presence and validity outcomes, using a key prefix (e.g., first 4 characters) to avoid storing full keys in logs. It records path, method, and event type to support monitoring and alerting.

For production, integrate with structured logging pipelines and ensure logs are retained and protected according to your security policies. Combine with rate limiting and alerting on repeated invalid key attempts to detect abuse. middleBrick scans can verify that such logging practices are present and that no sensitive data is inadvertently exposed in log outputs.

Frequently Asked Questions

What specific log entries should an Axum API with API keys produce to ensure sufficient visibility?

Log structured entries for each authentication event including: timestamp, client IP, request path, HTTP method, event type (auth_success or auth_failure), key ID prefix (not the full key), and outcome. Avoid logging full API keys.

How can I avoid logging sensitive API keys while still capturing useful audit data in Axum?

Log only non-sensitive metadata such as a key identifier or hash prefix, request path, method, and outcome. Use the tracing crate to emit structured events and ensure log redaction policies prevent full keys from being written to logs.

Insufficient Logging in Axum with Api Keys