Request Smuggling in Actix with Api Keys

Request smuggling occurs when an API gateway or backend framework parses HTTP requests differently than intended, allowing an attacker to smuggle a request across security boundaries. In Actix, this can arise when request parsing and routing are influenced by API key handling, especially when keys are passed via headers and not strictly isolated from request body processing.

Actix-web is a robust Rust framework, but if API key validation occurs after partial parsing of the request (for example, reading headers while the body is still being streamed), an attacker can craft requests that cause header smuggling. A common pattern involves an attacker sending a request with two Content-Length headers or a Transfer-Encoding header combined with an API key in a header. If Actix validates the API key but then forwards or logs the request in a way that reuses the same parsed headers and body, the second request may be interpreted as belonging to a different route or user.

Consider an Actix service that authenticates using an API key header and then passes the request downstream or internally via client calls. If the service does not fully separate the authentication layer from the request body stream, an attacker can send:

POST /api/resource HTTP/1.1
Content-Type: application/json
X-API-Key: legitimate-key
Transfer-Encoding: chunked

0

GET /admin/health HTTP/1.1
Host: service.internal
X-API-Key: legitimate-key

An implementation that reads the API key, starts processing the body as chunked, and then fails to reset or strictly delimit streams may allow the second request to be interpreted as part of the same connection. If internal routing or logging uses the same parser state, the smuggled request may bypass intended access controls tied to the API key. This becomes more impactful when the API key grants elevated permissions (e.g., service-to-service tokens) and the framework’s routing or middleware does not enforce strict request isolation between authenticated and downstream flows.

Middleware or wrappers that inspect headers for API keys before body consumption increase risk if they do not enforce strict parsing boundaries. For example, extracting the API key and then passing the request along without resetting the body stream can allow header-based smuggling across internal proxy layers or when Actix makes client requests to other services. The vulnerability is not in API keys themselves, but in how Actix pipelines combine authentication, streaming, and routing without ensuring that authenticated requests cannot alter the interpretation of subsequent requests on the same connection.

To mitigate request smuggling when using API keys in Actix, ensure strict separation between authentication and request body processing, and enforce canonical HTTP parsing. The following practices and code examples help reduce risk.

• Validate API keys before parsing the request body, and avoid mixing header inspection with streaming body reads in the same stage unless the body is buffered and reset.
• Use Actix’s PayloadConfig to limit payload size and enforce strict content-length or chunked decoding rules, preventing ambiguous transfer encodings that enable smuggling.
• Do not reuse request parts or connection state for downstream calls after authentication; create a new request builder to ensure separation.

Example: Secure API key extraction and request handling in Actix

use actix_web::{web, App, HttpRequest, HttpResponse, HttpServer, Responder, guard};
use actix_web::http::header;

async fn handle_request(req: HttpRequest, body: web::Json) -> impl Responder {
    // Extract API key early and reject if missing or invalid
    match req.headers().get("X-API-Key") {
        Some(key_header) if key_header == "valid-secret-key" => {
            // Process body only after successful authentication
            HttpResponse::Ok().json(serde_json::json!({ "status": "ok" }))
        }
        _ => HttpResponse::Unauthorized().json(serde_json::json!({ "error": "invalid api key" })),
    }
}

/// Configure payload limits to prevent ambiguous parsing
fn config_payload(cfg: &mut web::PayloadConfig) {
    cfg.limit(4096); // limit to 4KB to reduce DoS and parsing complexity
}

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

Example: Using middleware to enforce canonical parsing and prevent header smuggling

use actix_web::{dev::ServiceRequest, dev::ServiceResponse, Error, middleware::Next};
use actix_web::http::HeaderValue;

pub struct ApiKeyGuard;

impl actix_web::dev::Transform for ApiKeyGuard
where
    S: actix_web::dev::Service, Error = Error>,
    S::Future: 'static,
    B: 'static,
{
    type Response = ServiceResponse;
    type Error = Error;
    type Transform = ApiKeyGuardMiddleware;
    type InitError = ();
    type Future = std::future::Ready>;

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

pub struct ApiKeyGuardMiddleware {
    service: S,
}

impl actix_web::dev::Service for ApiKeyGuardMiddleware
where
    S: actix_web::dev::Service, Error = Error>,
    S::Future: 'static,
    B: 'static,
{
    type Response = ServiceResponse;
    type Error = Error;
    type Future = std::pin::Pin> + 'static>>;

    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 {
        // Strict header canonicalization: ensure only one API key header
        let key_headers: Vec<_> = req.headers().get_all("X-API-Key").iter().collect();
        if key_headers.len() != 1 {
            let res = HttpResponse::BadRequest().json(serde_json::json!({ "error": "invalid request" }));
            return Box::pin(async { Ok(req.into_response(res.into_body())) });
        }
        let key = &key_headers[0];
        if key != &HeaderValue::from_static("valid-secret-key") {
            let res = HttpResponse::Unauthorized().json(serde_json::json!({ "error": "invalid api key" }));
            return Box::pin(async { Ok(req.into_response(res.into_body())) });
        }

        // Continue processing with a fresh payload configuration to avoid stream state reuse
        let (head, payload) = req.into_parts();
        let config = actix_web::web::PayloadConfig::new(4096);
        let new_payload = config.new_payload(&head);
        let req = ServiceRequest::from_parts(head, new_payload);

        let fut = self.service.call(req);
        Box::pin(async move {
            let res = fut.await?;
            Ok(res)
        })
    }
}

// In main, attach the guard
#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .wrap(ApiKeyGuard)
            .route("/api/resource", web::post().to(|| async { HttpResponse::Ok().finish() }))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}