Api Key Exposure in Actix with Api Keys

Actix is a popular Rust web framework that enables high-performance APIs. When developers store static API keys in Actix application code, configuration files, or environment variables that are checked into source control, they create an exposure risk. These keys may appear in route handlers, middleware, or service constructors, and if responses or logs inadvertently include them, the keys can be exposed to unauthorized parties.

During a scan, middleBrick checks for indicators such as hardcoded strings resembling API keys in handler logic, unsafe serialization that echoes request or configuration data back to the client, and routes that return configuration or debug payloads containing credential-like values. Because Actix applications often integrate with external services, a compromised key can allow lateral movement to those services. The framework’s use of asynchronous handlers and extractor patterns can inadvertently surface keys when developers log extractor contents or pass sensitive data through response builders without redaction.

middleBrick’s unauthenticated, black-box scan exercises endpoints without credentials, looking for endpoints that return data typically protected by API keys, or that accept keys as query parameters or headers and reflect them in outputs. For example, an endpoint that echoes an Authorization header value or a custom x-api-key header in a JSON response can expose the key to anyone who can invoke the endpoint. The scan also inspectates OpenAPI specs when available, checking whether key-sensitive paths are described but not properly guarded by security schemes, and cross-references these definitions with runtime behavior to highlight mismatches.

Another exposure pattern in Actix arises from using query parameters to pass API keys, which can leak into server logs, browser history, and referrer headers. Keys embedded in URLs are more likely to be recorded inadvertently than keys passed in headers. middleBrick flags endpoints that accept keys via query params and checks whether responses include sensitive data or key material. Findings include references to relevant attack patterns such as credential leakage and information exposure, aligned with OWASP API Top 10 and common compliance frameworks.

When an OpenAPI specification is provided, middleBrick resolves full $ref chains and compares declared security requirements with actual runtime behavior. If an endpoint that should require an API key is open in practice, or if a spec describes key authentication but the implementation does not enforce it, the tool reports the discrepancy with prioritized findings and remediation guidance. This helps teams understand not only that a key is exposed, but how the exposure occurs in the context of their Actix routes and data flows.

Remediation focuses on preventing keys from appearing in responses, logs, or error messages, and ensuring they are transmitted and stored securely. Avoid echoing client-supplied headers or query parameters in JSON responses. Instead, validate and consume keys without including them in output bodies.

Example of vulnerable code that echoes an API key in a response:

use actix_web::{web, HttpResponse, Responder};

async fn echo_key(api_key: web::Query<ApiKey>) -> impl Responder {
    // Do not return the key in the response
    HttpResponse::Ok().json(serde_json::json!({ "key": api_key.key }))
}

#[derive(serde::Deserialize)]
struct ApiKey {
    key: String,
}

Safer approach: accept the key via extractor, validate it against a store or environment variable, and avoid including it in the response.

use actix_web::{web, HttpResponse, Result};
use std::env;

async fn validate_key(web::Query(params): web::Query<ApiKeyParams>) -> Result<HttpResponse> {
    let valid = env::var("API_KEY").map_or(false, |k| k == params.key);
    if valid {
        // Proceed with request logic; do not echo the key
        Ok(HttpResponse::Ok().json(serde_json::json!({ "status": "ok" })))
    } else {
        Ok(Err(actix_web::error::ErrorUnauthorized("invalid key")))
    }
}

#[derive(serde::Deserialize)]
struct ApiKeyParams {
    key: String,
}

For header-based keys, prefer extracting from headers rather than query parameters, and ensure responses do not include the key value.

use actix_web::{dev::ServiceRequest, Error, HttpMessage, HttpResponse, Result};
use actix_web::http::header::HeaderValue;
use actix_web::web::Bytes;
use std::str;

async fn handler(req: ServiceRequest) -> Result<HttpResponse> {
    match req.headers().get("x-api-key") {
        Some(h) => {
            let key = h.to_str().unwrap_or("");
            // Validate key without echoing it back
            if is_valid_key(key) {
                Ok(req.into_response(HttpResponse::Ok().finish()))
            } else {
                Ok(req.into_response(HttpResponse::Unauthorized().finish()))
            }
        }
        None => Ok(req.into_response(HttpResponse::Unauthorized().finish())),
    }
}

fn is_valid_key(key: &str) -> bool {
    // Compare with a securely stored key, e.g., from environment
    std::env::var("API_KEY").map_or(false, |k| k == key)
}

Additional remediation steps include removing keys from logs by customizing logging formats, ensuring debug endpoints do not return configuration details, and using secure storage for keys. middleBrick’s scans can verify that keys are not reflected in responses and that endpoints requiring keys are properly secured in both spec and implementation.