Phishing Api Keys in Actix with Api Keys

In Actix web applications, handling API keys typically involves reading a key from incoming request headers (e.g., x-api-key) and validating it before allowing access to a route. If the application implements only a basic presence check and then uses the key in a way that can be observed or inferred by an unauthenticated attacker, this combination can lead to a phishing-sensitive endpoint that reveals whether a given API key is valid. Such endpoints may leak information through timing differences or through crafted responses that confirm key validity, effectively enabling phishing where an attacker can probe keys via crafted requests.

Consider an Actix route that performs a simple string equality check to determine validity and then branches logic based on the result. If this route responds with different status codes or response body content depending on whether the key matches, an attacker can automate requests with guessed keys and infer validity from observable behavior. This becomes a phishing vector when the endpoint also processes or logs the key in a way that can be correlated with other signals, or when the application exposes stack traces or verbose errors that disclose internal path details.

An additional risk arises when API keys are passed in URLs as query parameters instead of headers; these keys can leak in server logs, browser history, and referrer headers. In an Actix service that parses keys from query strings and uses them to authorize downstream calls, a phishing-prone endpoint might inadvertently reflect the key or its usage, making it easier for an attacker to reuse captured keys. The combination of weak validation, inconsistent error handling, and key exposure in logs or URLs increases the likelihood of successful phishing attempts against API keys in Actix services.

Remediation focuses on making key validation constant-time and avoiding any observable branching based on key correctness. Use a constant-time comparison to prevent timing attacks, ensure errors are generic, and avoid logging or reflecting the raw key. Below are concrete Actix examples that demonstrate a secure approach.

First, use a constant-time comparison for key validation. The subtle crate provides ConstantTimeEq for this purpose. Here is a minimal, secure Actix handler:

use actix_web::{web, HttpResponse, Result};
use subtle::ConstantTimeEq;

// A stored key should be kept as bytes (e.g., from a secure source)
const VALID_KEY: &[u8] = b"example-secret-key-12345";

async fn validate_key_apikey(query: web::Query>) -> Result {
    // Prefer header-based keys; fallback to query for compatibility only
    let incoming = query.get("api_key").map(|s| s.as_bytes()).unwrap_or(b"");
    // Constant-time comparison to avoid timing leaks
    let valid = VALID_KEY.ct_eq(incoming).unwrap_or(0) == 1;
    if !valid {
        // Generic response; do not reveal which part failed
        return Ok(HttpResponse::Unauthorized().json(serde_json::json!({"error": "invalid request"})));
    }
    Ok(HttpResponse::Ok().json(serde_json::json!({"status": "authorized"})))
}

If you prefer header-based keys, an extractor can enforce presence and format without leaking information:

use actix_web::{dev::ServiceRequest, Error, FromRequest, HttpMessage, body::BoxBody};
use actix_web::http::header::HeaderValue;
use std::future::{ready, Ready};

struct ApiKey(String);

impl FromRequest for ApiKey {
    type Error = Error;
    type Future = Ready<Result>;

    fn from_request(req: &ServiceRequest, _: &mut actix_web::dev::Payload) -> Self::Future {
        const VALID_KEY: &str = "example-secret-key-123";
        let valid = req.headers()
            .get("x-api-key")
            .and_then(|v| v.to_str().ok())
            .map(|k| subtle::ConstantTimeEq::ct_eq(k.as_bytes(), VALID_KEY.as_bytes()).unwrap_or(0) == 1)
            .unwrap_or(false);
        if valid {
            req.extensions_mut().insert(ApiKey("ok".to_string()));
            ready(Ok(ApiKey("ok".to_string())))
        } else {
            ready(Err(actix_web::error::ErrorUnauthorized("invalid")))
        }
    }
}

async fn secured_route(_key: ApiKey) -> HttpResponse {
    HttpResponse::Ok().json(serde_json::json!({ "message": "access granted" }))
}

Additional measures include: never echoing the key in responses or logs, using HTTPS to prevent interception, rotating keys via a secure process, and avoiding query parameters for key transmission. These practices reduce phishing risk by removing confirmations or side channels that an attacker could exploit to probe valid keys in an Actix service.