Api Key Exposure in Actix with Basic Auth

Actix is a popular Rust web framework often used to build high-performance HTTP services. When Basic Auth is used without additional protections, API keys or session tokens can be inadvertently exposed in logs, error messages, or through misconfigured middleware. In Actix, developers commonly add Basic Auth via extractors or guards that parse the Authorization header and validate credentials. If the application logs request headers or responses in detail, the Base64-encoded credentials can be captured and stored in log aggregation systems.

Because Base64 is not encryption, any component that can read the logs or intercept the request pipeline can decode the credentials. In a microservice architecture where logs are centralized, this creates a broad exposure surface. middleBrick detects this by observing unauthenticated endpoints that return detailed headers or error payloads that include authorization data patterns. The scanner flags findings mapped to the Authentication and Data Exposure checks, noting that Basic Auth over HTTPS alone does not prevent logging or instrumentation leaks.

Another exposure vector arises when Actix applications are behind load balancers or API gateways that terminate TLS and forward requests internally over HTTP. In such setups, the Authorization header may be passed through to backend services or logged by infrastructure components. If the application does not strip or sanitize the Authorization header before logging, API keys embedded in credentials (for example, using a key as the password) can be written to disk or shipped to monitoring tools. middleBrick’s unauthenticated scan can surface these risks by probing endpoints that return verbose errors or headers, highlighting Data Exposure and Authentication issues without requiring credentials.

Additionally, improper handling of CORS and preflight requests in Actix can cause browsers to send Authorization headers on simple GET requests, which may be cached or logged by intermediary systems. If the application reflects the Authorization header in JSON error responses or debug payloads, an attacker who can read those responses can harvest credentials. The scanner’s Authentication check validates whether endpoints leak authorization context and provides remediation guidance to ensure headers are not echoed in responses.

To reduce exposure when using Basic Auth in Actix, avoid logging Authorization headers and enforce strict header sanitization. Below are concrete code examples that demonstrate secure patterns.

1. Basic Auth extractor with header sanitization

Use the actix_web::http::header::AUTHORIZATION header carefully and remove or mask sensitive values before logging.

use actix_web::{web, HttpRequest, HttpResponse, Result};
use actix_web::http::header;

async fn handler(req: HttpRequest) -> Result {
    // Extract Authorization header without logging it directly
    let auth_header = req.headers().get(header::AUTHORIZATION);
    // Mask the header before any logging or further processing
    if let Some(val) = auth_header {
        let masked = if val.to_str().map(|s| s.starts_with("Basic ")).unwrap_or(false) {
            "Basic [REDACTED]"
        } else {
            "[REDACTED]"
        };
        req.extensions_mut().insert(masked);
    }
    Ok(HttpResponse::Ok().body("ok"))
}

2. Custom middleware to strip sensitive headers

Add middleware that removes or overwrites the Authorization header for logging purposes and prevents it from being echoed in responses.

 actix_web::middleware::Transform for SensitiveHeaderStripper
where
    S: actix_web::dev::Service,
    S::Future: 'static,
{
    type Response = actix_web::dev::ServiceResponse;
    type Error = Error;
    type InitError = ();
    type Transform = SensitiveHeaderMiddleware;
    type Future = std::future::Ready>;

    fn new_transform(&self, service: S) -> Self::Future {
        std::future::ready(Ok(SensitiveHeaderMiddleware { service }))
    }
}

pub struct SensitiveHeaderMiddleware {
    service: S,
}

impl actix_web::dev::Service for SensitiveHeaderMiddleware
where
    S: actix_web::dev::Service,
    S::Future: 'static,
{
    type Response = actix_web::dev::ServiceResponse;
    type Error = Error;
    type Future = S::Future;

    fn poll_ready(&mut self, cx: &mut std::task::Context<'_>) -> std::task::Poll> {
        self.service.poll_ready(cx)
    }

    fn call(&mut self, mut req: ServiceRequest) -> Self::Future {
        // Remove or replace the Authorization header to avoid logging it
        req.headers_mut().remove(header::AUTHORIZATION);
        let _ = req.headers_mut().insert(header::AUTHORIZATION, "Basic [REDACTED]".parse().unwrap());
        self.service.call(req)
    }
}

use actix_web::{App, HttpServer};

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            // Security headers and HTTPS enforcement should be applied at the server or proxy layer
            .wrap(SensitiveHeaderStripper)
            .route("/secure", actix_web::web::get().to(|| async { "secure" }))
    })
    .bind_rustls_aws("0.0.0.0:8443", rustls_config())? // example placeholder
    .run()
    .await
}

fn rustls_config() -> rustls::ServerConfig {
    // Provide proper certificate and key loading here
    unimplemented!()
}