Request Smuggling in Axum with Mutual Tls

Request smuggling is an HTTP protocol violation where an attacker can cause the frontend (e.g., a load balancer or reverse proxy terminating Mutual TLS) and the backend (e.g., an Axum service) to interpret request boundaries differently. With Mutual TLS enabled, the frontend validates client certificates before forwarding traffic, which can create a false sense of security. If the frontend uses one parsing strategy (e.g., lenient header merging) and Axum uses another (strict Rust hyper parsing), inconsistencies around Transfer-Encoding and Content-Length can be exploited. For example, a malicious client can send a request with both Transfer-Encoding and Content-Length headers; the frontend may treat one message as the end of the request while Axum parses an additional request hidden inside, allowing unauthorized requests to reach backend routes that would otherwise require authentication.

Mutual TLS does not prevent parsing ambiguities; it only authenticates peers. In Axum, if route handlers or middleware do not explicitly reject ambiguous or malformed framing, an attacker can smuggle requests to access admin endpoints, bypass intended authorization boundaries, or leak response bodies meant for prior requests. This is especially risky when Axum sits behind a gateway that normalizes headers before forwarding, because the gateway might drop or modify headers in a way that Axum interprets differently. Common attack patterns like CL.TE or TE.CL can cause Axum to process a smuggled request in the context of an authenticated session, leading to BOLA/IDOR or unauthorized actions without triggering Mutual TLS rejection.

Because middleBrick scans the unauthenticated attack surface, it can detect inconsistencies in how headers are handled across the frontend and Axum. Findings may highlight missing frame validation or improper header handling that enable smuggling, even when Mutual TLS is active. Remediation requires aligning parsing and rejection rules between layers and ensuring Axum strictly validates message framing before processing.

To mitigate request smuggling in Axum with Mutual TLS, enforce strict HTTP message parsing and reject ambiguous or conflicting headers. Below are concrete, syntactically correct examples that demonstrate how to configure TLS and validate requests in Axum.

Mutual TLS setup in Axum

Use tower-http with TLS configuration to require client certificates and enforce strict header handling. This example shows a minimal Axum service with Mutual TLS enabled:

use axum::Router;
use tower_http::set_header::SetResponseHeaderLayer;
use tower_http::trace::TraceLayer;
use std::net::SocketAddr;
use axum::routing::get;

async fn handler() -> &'static str {
    "ok"
}

#[tokio::main]
async fn main() {
    let app = Router::new()
        .route("/", get(handler))
        // Reject requests that have both Content-Length and Transfer-Encoding
        .layer(SetResponseHeaderLayer::overriding(
            tower_http::headers::HeaderName::from_static("x-content-length-check"),
        ))
        .layer(TraceLayer::new_for_http());

    let tls_config = tower_rustls::TlsAcceptor::new(
        rustls::ServerConfig::builder()
            .with_safe_defaults()
            .with_no_client_auth() // will be overridden by client_auth
            .with_client_auth_cert(vec!["ca-cert.pem".into()], rustls::NoClientAuth::new())
            .expect("valid client auth"),
    );

    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .tls_config(tls_config)
        .expect("valid TLS config")
        .serve(app.into_make_service())
        .await
        .unwrap();
}

Strict header validation middleware

Add middleware that rejects requests with smuggling-prone header combinations. This ensures Axum processes a consistent message format:

use axum::{async_trait, extract::Request, middleware::Next};
use http::{header, Response};

pub struct HeaderValidationLayer;

impl tower::Layer for HeaderValidationLayer {
    type Service = HeaderValidationService;

    fn layer(&self, inner: S) -> Self::Service {
        HeaderValidationService { inner }
    }
}

pub struct HeaderValidationService {
    inner: S,
}

impl tower::Service> for HeaderValidationService
where
    S: tower::Service, Response = Response> + Clone + Send + 'static,
    S::Future: Send + 'static,
    B: Send + 'static,
{
    type Response = S::Response;
    type Error = S::Error;
    type Future = async_stream::BoxStream<'static, Result>;

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

    fn call(&mut self, mut req: Request) -> Self::Future {
        let has_te = req.headers().contains_key(header::TRANSFER_ENCODING);
        let has_cl = req.headers().contains_key(header::CONTENT_LENGTH);

        if has_te && has_cl {
            let response = Response::builder()
                .status(400)
                .body(hyper::Body::from("Invalid headers: TE and CL both present"))
                .unwrap();
            return async_stream::stream::once(async { Ok(response) }).boxed();
        }

        async_stream::stream::once(async move { self.inner.call(req).await }).boxed()
    }
}