Phishing Api Keys in Actix with Hmac Signatures

When API keys are transmitted or verified in an Actix web service using Hmac Signatures, the risk of phishing API keys arises from implementation weaknesses rather than the cryptographic primitive itself. A phishing API key scenario occurs when an application accepts API keys in an unsafe manner—such as via query parameters, non-HTTPS channels, or predictable header placement—allowing an attacker to capture or replay them. Even when Hmac Signatures are used to sign requests, if the signing process does not tightly bind the key to the request context (method, path, body, timestamp), a captured key and signature can be reused in a phishing attack against another endpoint.

Consider an Actix service that expects an x-api-key header and an x-signature header, where the signature is an HMAC-SHA256 of the request payload using the API key as the secret. If the service does not include the HTTP method, request path, and a nonce or timestamp in the signed string, an attacker who observes a valid signed request can replay it to another method or path that also trusts the same key. This is especially dangerous when the Actix application exposes both public and privileged endpoints under the same service and relies only on the API key for authorization without additional property-based or role-based checks.

Insecure deserialization of headers, body, or query parameters in Actix handlers can further enable phishing by allowing an attacker to forge or manipulate inputs so that a valid Hmac-signed request is accepted for a different intent than intended. For example, if the signature is computed over a JSON body but the server parses the body before verifying the Hmac, an attacker might modify the JSON after replaying the request. The combination of a static API key used for Hmac and missing contextual binding increases the likelihood that intercepted credentials can be used elsewhere, effectively turning the API key into a phishing target.

To detect such risks, middleBrick scans unauthenticated attack surfaces and checks whether API keys are exposed in logs, error messages, or client-side code, and whether Hmac implementations include critical context like method, path, and timestamps. Findings from scans include concrete remediation guidance tied to frameworks such as OWASP API Top 10 and reference real-world patterns like those seen in CVE-prone implementations.

Secure Hmac usage in Actix requires binding the signature to the full request context and ensuring keys are never exposed in logs or URLs. Below are concrete, safe patterns for generating and verifying Hmac Signatures in Actix web services.

use actix_web::{web, App, HttpRequest, HttpResponse, HttpServer, Responder};
use hmac::{Hmac, Mac};
use sha2::Sha256;
use std::time::{SystemTime, UNIX_EPOCH};

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

/// Build the signing string from method, path, timestamp, and body.
/// This binds the signature to critical request context to prevent replay.
fn build_signing_string(method: &str, path: &str, timestamp: u64, body: &str) -> String {
    format!("{}|{}|{}|{}", method, path, timestamp, body)
}

/// Verify the signature in an Actix extractor.
async fn verify_hmac(
    req: HttpRequest,
    body: String,
    api_key: &str,
    signature_header: &str,
) -> bool {
    let timestamp = match req.headers().get("x-timestamp") {
        Some(val) => match val.to_str().ok().and_then(|s| s.parse::().ok()) {
            Some(ts) => ts,
            None => return false,
        },
        None => return false,
    };

    // Reject old timestamps to prevent replay (e.g., 5-minute window)
    let now = SystemTime::now()
        .duration_since(UNIX_EPOCH)
        .map(|d| d.as_secs())
        .unwrap_or(0);
    if now.saturating_sub(timestamp) > 300 {
        return false;
    }

    let signing_string = build_signing_string(
        req.method().as_str(),
        req.path(),
        timestamp,
        &body,
    );

    // Verify HMAC
    let mut mac = HmacSha256::new_from_slice(api_key.as_bytes())
        .expect("HMAC can take key of any size");
    mac.update(signing_string.as_bytes());
    match hex::decode(signature_header) {
        Ok(expected_sig) => mac.verify_slice(&expected_sig).is_ok(),
        Err(_) => false,
    }
}

/// Example handler that requires HMAC verification.
async fn protected_handler(
    req: HttpRequest,
    body: String,
) -> impl Responder {
    let api_key = match req.headers().get("x-api-key") {
        Some(v) => match v.to_str() {
            Ok(s) => s,
            Err(_) => return HttpResponse::BadRequest().finish(),
        },
        None => return HttpResponse::Unauthorized().finish(),
    };

    let signature = match req.headers().get("x-signature") {
        Some(v) => match v.to_str() {
            Ok(s) => s,
            Err(_) => return HttpResponse::BadRequest().finish(),
        },
        None => return HttpResponse::Unauthorized().finish(),
    };

    if verify_hmac(req, body.clone(), api_key, signature).await {
        HttpResponse::Ok().body("Authenticated and valid request")
    } else {
        HttpResponse::Unauthorized().finish()
    }
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .route("/api/action", web::post().to(protected_handler))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

This example demonstrates key binding by including the HTTP method, path, timestamp, and body in the signed string. The timestamp enables replay protection; requests outside a short window are rejected. Never include the API key in the signed string itself, and avoid using it directly as a non-secret identifier.

For production use, rotate keys periodically, store them securely outside the codebase, and enforce HTTPS to prevent key interception. middleBrick can validate that your deployment avoids key leakage in query strings or error responses and that Hmac bindings include necessary context, reducing the phishing surface.