Token Leakage in Actix with Hmac Signatures

Token leakage in Actix applications that rely on Hmac Signatures for request authentication occurs when signature material or derived tokens are unintentionally exposed in logs, error messages, URLs, or cross-service flows. In an Actix web service, Hmac Signatures are typically computed over a canonical representation of the request (method, path, selected headers, and body) using a shared secret. The resulting signature is often passed in a header such as x-api-signature or included as a query parameter. When the implementation or surrounding infrastructure does not carefully control data exposure, the signature or the tokens derived from it can leak beyond the intended security boundary.

One common path to leakage is verbose or misconfigured logging. If Actix request handling code logs the full request URL, headers, or parsed query parameters—including the signature or API key identifiers—an attacker who can read logs or error output can harvest the token or replay it. Another vector is improper error handling: detailed error pages or JSON error responses that include the full request headers may inadvertently surface the Hmac signature. URLs exacerbate the risk because query parameters are stored in server logs, browser history, and Referer headers; placing the signature in a query parameter rather than a header increases exposure. Cross-service leakage is also possible: if an Actix service forwards requests to downstream services and propagates the same Authorization or custom signature headers without stripping or re-signing, the token can leave the trusted boundary. Insecure deserialization or unsafe consumption of messages (a check performed by middleBrick) can further allow tampered or replayed token data to propagate across the system. Together, these channels turn Hmac Signatures into a bearer token; if leaked, an attacker can impersonate legitimate clients until the secret is rotated and affected sessions are invalidated.

middleBrick’s LLM/AI Security checks and broader API scans help surface these risks by testing unauthenticated attack surfaces and flagging items such as Data Exposure and Unsafe Consumption. The scan evaluates whether signatures or sensitive tokens appear in logs, error responses, or outbound calls, and maps findings to relevant parts of the OWASP API Top 10 and compliance frameworks. By correlating runtime behavior with spec definitions (including full $ref resolution), the tooling identifies mismatches between intended authentication flow and actual leakage paths.

Remediation focuses on ensuring Hmac Signatures are never unnecessarily duplicated, logged, or exposed in URLs, and that they are validated and handled consistently within Actix middleware. Prefer transmitting the signature in a dedicated header (e.g., x-api-signature) rather than a query parameter, and enforce strict referrer and logging hygiene. Below are concrete, realistic code examples for an Actix web service that demonstrate secure handling of Hmac Signatures.

Example: Secure Hmac Signature generation and verification in Actix (Rust)

use actix_web::{dev::ServiceRequest, Error, HttpMessage};
use chrono::{DateTime, Utc};
use hmac::{Hmac, Mac};
use sha2::Sha256;
use std::collections::HashMap;

// Type alias for Hmac-SHA256
 type HmacSha256 = Hmac;

/// Canonicalize selected headers and method/path for signing.
fn canonical_string(req: &ServiceRequest, headers_to_sign: &[&str]) -> String {
    let method = req.method().to_string();
    let path = req.path().to_string();
    let timestamp: DateTime<Utc> = Utc::now().into();
    // Include timestamp to prevent replay; store in request extensions for later verification
    req.extensions_mut().insert(timestamp.clone());

    let mut items = vec![format!("{}:{}:{}:timestamp={}", method, path, timestamp)];
    for &hdr in headers_to_sign {
        if let Some(val) = req.headers().get(hdr) {
            items.push(format("{}:{}:value={}", hdr, val.to_string_lossy()));
        }
    }
    items.join("&")
}

/// Compute Hmac signature over canonical string.
fn compute_signature(secret: &[u8], canonical: &str) -> String {
    let mut mac = HmacSha256::new_from_slice(secret).expect("HMAC can take key of any size");
    mac.update(canonical.as_bytes());
    let result = mac.finalize();
    let code = result.into_bytes();
    hex::encode(code)
}

/// Middleware to add signature to request extensions (do NOT log it).
pub async fn with_hmac_signature(secret: &[u8], headers_to_sign: Vec<&'static str>) -> impl Fn(ServiceRequest) -> actix_web::Result {
    move |req: ServiceRequest| {
        let canonical = canonical_string(&req, &headers_to_sign);
        let sig = compute_signature(secret, &canonical);
        // Store signature and canonical form for downstream verification, not logging
        req.extensions_mut().insert(sig);
        actix_web::dev::ServiceRequest::ok(req)
    }
}

/// Verify signature at handler or a dedicated validation middleware.
pub fn verify_hmac_signature(secret: &[u8], req: &ServiceRequest) -> bool {
    let canonical = canonical_string(req, &["x-client-id", "timestamp"]);
    let expected_sig = compute_signature(secret, &canonical);
    // Retrieve signature from header (never from query)
    let received = match req.headers().get("x-api-signature") {
        Some(v) => v.to_str().unwrap_or_default(),
        None => return false,
    };
    // Constant-time compare to avoid timing leaks
    received == expected_sig
}

Key practices illustrated:

• Do not log the signature or the full canonical string; avoid printing request URLs that include query-based tokens.
• Transmit the signature in a header (x-api-signature) rather than a query parameter to reduce logging and Referer exposure.
• Include a timestamp and reject stale requests to limit replay windows; store timestamp in request extensions, not in logs.
• Validate the signature in middleware or handler using a constant-time comparison to prevent timing attacks.
• Strip or do not propagate the signature header when forwarding to downstream services unless they require re-signing with their own secret.

Operational hygiene also matters: rotate Hmac secrets periodically, use environment-managed secret storage, and ensure that any structured logging or error serialization excludes header values that may carry the signature. middleBrick’s scans can highlight remaining leakage vectors such as Data Exposure and Unsafe Consumption, enabling teams to tighten logging rules and error handling specific to Actix services.