Http Request Smuggling in Axum with Cockroachdb

HTTP Request Smuggling arises when an API service parses HTTP messages differently between a frontend proxy/load balancer and the application server. In an Axum service backed by CockroachDB, the risk is not that CockroachDB introduces smuggling, but that the Axum app and its deployment topology create conditions where smuggling can be leveraged to bypass authorization, poison caches, or leak data. Smuggling typically requires two parsing discrepancies: one that allows an attacker to inject an extra request into the pipeline, and another that causes one layer to treat that injected request as part of the next transaction.

An Axum app running behind a reverse proxy or API gateway can exhibit a request smuggling vector when the proxy and Axum interpret Transfer-Encoding and Content-Length differently. For example, a proxy might forward a request with both Transfer-Encoding: chunked and a Content-Length header, while Axum (depending on the underlying hyper settings and how you read the body) may prioritize one header over the other. If the proxy uses Content-Length to frame the request body and Axum falls back to chunked parsing, an attacker can craft a request where the body contains an additional, smuggled request. Because CockroachDB is only a backend datastore, smuggling does not originate from CockroachDB itself, but a compromised Axum handler can execute unintended SQL statements against CockroachDB on behalf of an attacker, leading to unauthorized data access or modification.

Consider an endpoint that accepts a JSON payload to query or update user data in CockroachDB. If Axum does not strictly validate message boundaries and your proxy does not normalize requests, an attacker can send:

POST /updateProfile HTTP/1.1
Content-Length: 71
Transfer-Encoding: chunked

0

GET /admin/users HTTP/1.1
Host: api.example.com
Authorization: Bearer 
Content-Length: 0

A proxy that processes Content-Length=71 may read the body as one chunk and forward it, while Axum may parse the chunked body and treat the second request as a separate transaction handled by the same connection. If the Axum route for /updateProfile inadvertently uses elevated permissions when interacting with CockroachDB, the smuggled request could execute sensitive SQL statements. CockroachDB’s SQL layer does not introduce smuggling, but it can amplify impact if compromised queries are forwarded without proper tenant or user context checks.

Another scenario involves HTTP/2 prior knowledge and request coalescing in the proxy. If Axum services are deployed with HTTP/2 and the proxy does not strictly separate streams, an attacker might induce cross-stream dependency issues that lead to request mixing. Because Axum routes are often organized around database operations with CockroachDB, a smuggled request can target different tenant IDs or impersonate another user. The root cause is a mismatch in how requests are framed and parsed between layers, not in CockroachDB itself, but the database becomes the target of malicious SQL if Axum fails to enforce strict request isolation.

To detect this class of issue, scans should compare how the proxy normalizes headers like Content-Length and Transfer-Encoding and verify that Axum consistently rejects ambiguous or conflicting headers. Tools that perform black-box request smuggling tests can probe these edge cases without needing authentication, and findings should map the risk to the API security score, highlighting weaknesses in input validation and rate limiting that could enable smuggling against CockroachDB-backed services.

Remediation focuses on ensuring Axum enforces strict HTTP message parsing and does not allow ambiguous headers to create additional request boundaries. The goal is to make Axum behave predictably regardless of proxy behavior, and to ensure every database interaction with CockroachDB is scoped to the authenticated and authorized user.

1. Normalize and reject conflicting headers in Axum

Do not allow both Content-Length and Transfer-Encoding in the same request. Implement a middleware or extractor that rejects requests with conflicting framing headers before they reach your routes.

use axum::{{
    async_trait,
    extract::{FromRequest, Request},
    http::{self, HeaderName, HeaderValue},
    response::Response,
    Extension,
}};
use std::convert::Infallible;

/// Middleware that rejects requests with both Content-Length and Transfer-Encoding
pub async fn header_normalization_middleware(
    Extension(_): Extension<AppState>,
    mut req: Request,
) -> Result<Request, (http::StatusCode, String)> {
    let has_content_length = req.headers().contains_key(http::header::CONTENT_LENGTH);
    let has_transfer_encoding = req.headers().contains_key(http::header::TRANSFER_ENCODING);

    if has_content_length && has_transfer_encoding {
        return Err((http::StatusCode::BAD_REQUEST, "Conflicting headers: Content-Length and Transfer-Encoding".to_string()));
    }
    Ok(req)
}

2. Enforce strict body parsing and avoid header-based body decisions

When reading the body, prefer chunked parsing and do not switch behavior based on header values supplied by the client. Use Axum’s built-in JSON extractor which handles framing deterministically.

use axum::{{
    routing::post,
    Router,
    extract::Json,
    http::StatusCode,
}};
use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize, Serialize)]
struct ProfileUpdate {
    user_id: i64,
    display_name: String,
}

async fn update_profile(
    Json(payload): Json<ProfileUpdate>,
    // Assume Extension(pool) provides a CockroachDB connection pool
) -> Result<StatusCode, (StatusCode, String)> {
    // Use parameterized SQL to avoid injection; scope to user_id from payload
    let result = sqlx::query(
        "UPDATE profiles SET display_name = $1 WHERE id = $2 AND tenant_id = $3"
    )
    .bind(&payload.display_name)
    .bind(payload.user_id)
    .bind(current_tenant_id()) // implement tenant resolution safely
    .execute(&pool)
    .await
    .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    if result.rows_affected() == 0 {
        return Err((StatusCode::FORBIDDEN, "Update not permitted".into()));
    }
    Ok(StatusCode::OK)
}

fn app() -> Router {
    Router::new()
        .route("/updateProfile", post(update_profile))
        .layer(axum::middleware::from_fn(header_normalization_middleware))
}

3. Scope database operations to the authenticated user and tenant

Even if smuggling is prevented at the HTTP layer, ensure that SQL execution always includes tenant and user context derived from authentication, never from request parameters alone. Use strongly-typed queries and avoid dynamic SQL built from headers or cookies.

// Example tenant resolution from JWT or session, not from request
async fn current_tenant_id() -> i64 {
    // Implement proper auth extraction; this is a placeholder
    1
}

4. Proxy and deployment hygiene

Configure your reverse proxy or API gateway to normalize requests: strip conflicting headers, enforce a single framing mechanism, and avoid passing through malformed messages to Axum. Regularly test the deployed setup with unauthenticated scans to confirm that smuggling attempts are rejected with a consistent 400 response.

These fixes ensure that Axum handles requests deterministically and that CockroachDB interactions are safely scoped, reducing the risk that a smuggling vulnerability can be leveraged to execute unauthorized SQL.