Api Key Exposure in Actix with Bearer Tokens

Actix is a popular Rust web framework that enables high-performance APIs. When developers use Bearer Tokens for authentication, they often embed tokens in HTTP headers (Authorization: Bearer ). If routes are inadvertently exposed or misconfigured, these tokens can leak through logs, error messages, or open endpoints. This typically happens when developers expose unauthenticated or weakly authenticated endpoints alongside authenticated ones, allowing an unauthenticated attacker to harvest API keys used by services or third‑party integrations.

In a black-box scan, middleBrick tests the unauthenticated attack surface and checks whether sensitive endpoints disclose tokens or whether authentication is bypassed via route confusion or improper header handling. For example, if an Actix app defines a health or debug route that echoes headers, an attacker can send a request with a Bearer Token and observe the response, leading to key exposure. MiddleBrick’s checks include detecting missing authentication on routes that should be protected, insecure HTTP methods, and endpoints that reflect authorization headers without redaction. These findings map to the Authentication and Data Exposure categories, with severity determined by whether tokens are echoed, logged, or returned in responses.

Additionally, improper CORS or permissive route definitions in Actix can widen the attack surface. If an Actix handler reads the Authorization header and includes it in logs or error payloads, tokens may be exposed in plaintext or in structured logs that are accessible to less-privileged actors. MiddleBrick’s unauthenticated scans surface these risks by probing routes and analyzing responses for token leakage patterns, ensuring that developers understand where API keys are at risk without needing to run a full authenticated test suite.

To mitigate Bearer Token exposure in Actix, ensure that authentication is enforced on all sensitive routes and that tokens are never reflected or logged. Below are concrete, safe patterns using the Actix-web framework.

Secure extractor pattern with guard: Use a guarded extractor to reject requests without a valid Bearer Token and avoid falling back to unauthenticated handlers.

use actix_web::{web, App, HttpServer, HttpResponse, Error};
use actix_web::http::header::HeaderValue;
use actix_web::dev::ServiceRequest;
use actix_web::error::ErrorUnauthorized;
use futures::future::{ok, Ready};

fn validate_bearer(req: ServiceRequest) -> Result {
    let headers = req.headers();
    match headers.get("Authorization") {
        Some(auth_header) => {
            let header_str = auth_header.to_str().unwrap_or("");
            if header_str.starts_with("Bearer ") {
                let token = &header_str[7..];
                // Replace with actual validation (e.g., verify against a store)
                if token == "VALID_TOKEN_EXAMPLE" {
                    return Ok(req);
                }
            }
            Err((ErrorUnauthorized("Invalid or missing token"), req))
        }
        None => Err((ErrorUnauthorized("Missing Authorization header"), req)),
    }
}

async fn protected_route() -> HttpResponse {
    HttpResponse::Ok().body("Authenticated data")
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .route("/api/secure", web::get().to(protected_route).guard(guard::Header("Authorization", "Bearer VALID_TOKEN_EXAMPLE")))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

Middleware to strip tokens from logs: Implement logging that redacts the Authorization header to avoid accidental exposure in application logs.

 String {
    let headers = req.headers();
    let auth = headers.get("Authorization")
        .map(|h| "Authorization: [REDACTED]")
        .unwrap_or_else(|| "Authorization: missing".to_string());
    format!("{} {}", req.method(), auth)
}

// In your Actix logger configuration, use a custom format or filter:
actix_web::middleware::Logger::new("{method} {uri} {auth}")
    .logfn(|target, level, record| {
        info!("{} - {}", sanitize_log_headers(record.request()), record.args());
    });

Avoid echoing tokens in responses: Ensure handlers do not return the token in JSON or error messages. Always validate on the server side and use opaque references instead of raw tokens where possible.

By combining route guards, secure extractors, and careful logging, developers can reduce the risk of API key exposure while still leveraging Bearer Tokens for authentication in Actix services.