Insufficient Logging in Actix with Hmac Signatures

Insufficient logging in Actix web services that use HMAC signatures for request authentication can obscure abuse and hinder incident response. When HMAC is used, the signature is typically computed over selected parts of the request—such as the HTTP method, path, selected headers, and the request body—using a shared secret. If the application does not log enough context, an attacker’s crafted, signed requests may leave minimal or ambiguous traces.

Consider an Actix endpoint that expects an HMAC-SHA256 signature in a custom header like X-API-Signature. If the server only validates the signature and does not record key details, a brute‑force or replay attempt may succeed without any actionable log entry. Effective logging for HMAC‑protected endpoints should capture at minimum: the timestamp, the request path, the HTTP method, the signature (or a redacted representation), the key identifier used to select the shared secret, client‑supplied identifiers (e.g., an API key or user ID), and the outcome of the validation step. Without these, correlating failed signature verifications with an attacker probing multiple keys or nonce values is difficult.

Additionally, Actix middleware that verifies HMAC signatures may process requests before reaching the handler. If middleware logs only success cases and silently rejects invalid signatures, anomalous patterns—such as a high rate of invalid signatures from a single IP—go unnoticed. Logging should occur both at the point of signature validation and within the handler, capturing the normalized request representation used to compute the HMAC (e.g., sorted headers, canonical body). This enables defenders to detect timing differences, malformed requests targeting implementation bugs, or attempts to misuse optional body encodings that change the signed payload.

Real attack patterns such as replaying captured requests or systematically trying different shared secrets rely on the absence of detailed logs. For example, an attacker could replay a legitimate signed POST with an altered body; if the server does not log the body hash or a unique nonce, the replay may appear as a normal transaction. By ensuring logs include a stable, logged representation of the request that was used for HMAC verification, teams can detect duplicate or out‑of‑order requests and tie them back to a specific client. This is especially important when the implementation uses optional query parameters or custom headers that influence signature computation; omitting these from logs creates blind spots.

Remediation centers on structured logging at the point of signature validation and within request handlers, combined with canonical request building so logs can be reliably compared against runtime behavior. In Actix, you can implement middleware that extracts and validates the HMAC, logs the necessary details, and then passes the request to the handler.

Below is an example of HMAC‑SHA256 validation in Actix with comprehensive logging. The code captures method, path, key identifier, a redacted signature, client identifier, timestamp, and validation outcome. It uses a helper to produce a canonical string for signing and a constant‑time comparison to avoid leaking timing information through logs or responses.

use actix_web::{dev::ServiceRequest, dev::ServiceResponse, Error, HttpMessage};
use actix_web::body::to_bytes;
use actix_web::http::{HeaderMap, Method, Uri};
use log::{info, warn};
use std::collections::HashMap;
use std::time::{SystemTime, UNIX_EPOCH};

/// Compute the canonical string used for signing.
/// This must match the client’s signing process.
fn canonical_request(method: &Method, uri: &Uri, headers: &HeaderMap, body: &[u8]) -> String {
    let method = method.as_str().to_uppercase();
    let path = uri.path().to_string();
    // Example: include selected headers and a hash of the body.
    let headers_to_sign = ["content-type", "x-request-id"];
    let mut header_parts: Vec = Vec::new();
    for name in &headers_to_sign {
        if let Some(value) = headers.get_all(name.iter().map(|&c| c).collect::>().as_str()).get(0) {
            header_parts.push(format!("{}:{}", name.to_lowercase(), value.to_str().unwrap_or("")));
        }
    }
    let body_hash = hex::encode(sha2::Sha256::digest(body));
    format!("{}\n{}\n{}\n{}", method, path, header_parts.join("&"), body_hash)
}

/// Extract a stable representation for logging (do not log raw signature).
fn redacted_signature(sig: &str) -> String {
    let len = sig.len();
    if len <= 6 {
        "REDACTED".to_string()
    } else {
        let keep = &sig[..3];
        let end = &sig[len - 3..];
        format!("{}...{}", keep, end)
    }
}

/// Middleware-like function to validate HMAC and log details.
async fn validate_hmac_and_log(req: ServiceRequest, shared_secret: &[u8]) -> Result {
    let start = SystemTime::now();
    let method = req.method().clone();
    let uri = req.uri().clone();
    let headers = req.headers();
    let key_id = headers.get("X-API-Key").map(|v| v.to_str().unwrap_or("unknown")).unwrap_or("unknown");
    let sig = headers.get("X-API-Signature").map(|v| v.to_str().unwrap_or("").to_string()).unwrap_or_default();

    let body = match to_bytes(req.request().clone(), 8192).await {
        Ok(b) => b,
        Err(_) => {
            warn!(target: "hmac_validation", "missing_body");
            return Err((actix_web::error::ErrorBadRequest("body_error"), req));
        }
    };

    let canonical = canonical_request(&method, &uri, headers, &body);
    let computed = hmac::Hmac::::new_from_slice(shared_secret)
        .map(|mut mac| {
            mac.update(canonical.as_bytes());
            mac.finalize().into_bytes()
        })
        .map_err(|_| (actix_web::error::ErrorBadRequest("hmac_init_error"), req))?;
    let computed_hex = hex::encode(computed);
    let valid = subtle::ConstantTimeEq::ct_eq(computed.as_ref(), sig.as_ref()).into()
        || subtle::ConstantTimeEq::ct_eq(computed_hex.as_ref(), sig.as_ref()).into();

    let ts = start.duration_since(UNIX_EPOCH).map(|d| d.as_millis()).unwrap_or(0);
    if valid {
        info!(target: "hmac_validation",
            timestamp={ts},
            method=%method,
            path=%uri.path(),
            key_id=%key_id,
            signature={redacted_signature(&sig)},
            validation="success"
        );
    } else {
        warn!(target: "hmac_validation",
            timestamp={ts},
            method=%method,
            path=%uri.path(),
            key_id=%key_id,
            signature={redacted_signature(&sig)},
            validation="failure"
        );
    }

    if valid {
        Ok(req)
    } else {
        Err((actix_web::error::ErrorUnauthorized("invalid_signature"), req))
    }
}

/// Example handler that also logs outcome.
async fn example_handler() -> &'static str {
    "ok"
}

/// Integration sketch: attach validation in Actix App data or as a service wrapper.
/// This is a conceptual sketch; adapt to your middleware chain.
/*
fn configure_routes(cfg: &mut web::ServiceConfig) {
    cfg.service(
        web::resource("/api/endpoint")
            .route(web::post().to(|req: ServiceRequest| async move {
                validate_hmac_and_log(req, b"my_shared_secret").await?;
                let resp = example_handler().await;
                Ok(actix_web::HttpResponse::Ok().body(resp))
            }))
    );
}
*/

Key points in this remediation:

• Log the request representation used for signing (headers and body hash) so the logged data can be replayed for testing or audit.
• Redact the full signature in logs to avoid exposing secrets while still allowing pattern analysis (e.g., malformed length).
• Log the key identifier used to select the shared secret to support key rotation and incident correlation.
• Log both validation success and failure with timestamps to detect bursts of invalid signatures indicative of probing.
• Use constant‑time comparison for signature verification to avoid timing side‑channels that could leak information useful to attackers.

By combining canonical request logging with structured, targeted log entries, teams can detect and investigate HMAC‑related abuse while preserving the security properties of the signing scheme.