Sql Injection Blind in Axum (Rust)

SQL Injection Blind in an Axum application written in Rust arises when user-controlled input is concatenated into SQL queries without proper parameterization. Axum does not provide its own database layer; it relies on the runtime async ecosystem, commonly sqlx or diesel. If developers build query strings using string formatting or concatenation, the application becomes vulnerable regardless of the language’s memory safety guarantees.

Consider a typical handler that extracts a query parameter and interpolates it into a SQL statement:

let user_id = req.query_params().get("id").unwrap_or("1");
let query = format!("SELECT * FROM users WHERE id = {}", user_id); // Unsafe
sqlx::query(&query).fetch_one(&pool).await?;

Even though Rust prevents buffer overflows, this pattern enables SQL Injection Blind because the input is treated as executable SQL syntax rather than data. An attacker can supply id=1 OR 1=1 to infer data existence via timing differences or conditional error behavior, which is characteristic of SQL Injection Blind. The absence of prepared statements or bound parameters means the database cannot distinguish between code and content.

Axum’s extractor model can inadvertently encourage this anti-pattern when route extractors or query parsers feed unchecked strings into SQL construction routines. Because the scan targets the unauthenticated attack surface, an endpoint that echoes user input in query building may be probed for boolean-based or time-based inference techniques. Real-world examples include CVE patterns where authentication bypass or data exfiltration is achieved through carefully crafted payloads that manipulate conditional logic in WHERE clauses without causing crashes.

Moreover, the interplay between Axum’s routing and runtime query building can obscure the injection path during manual review. The use of dynamic SQL in combination with optional parameters increases the attack surface. The scanner’s 12 security checks, including Input Validation and Property Authorization, are designed to detect such injection risks by analyzing OpenAPI specs and correlating them with runtime behavior, identifying places where untrusted data reaches SQL-like operations without sanitization or parameterization.

Remediation in Axum with Rust centers on using parameterized queries via sqlx or an ORM that supports bound parameters. This ensures user input is never interpreted as SQL syntax. Below are concrete, working examples that replace string concatenation with safe patterns.

Unsafe pattern to avoid:

// DO NOT DO THIS
let query = format!("SELECT * FROM users WHERE email = '{}'", email);
sqlx::query(&query).fetch_one(&pool).await?;

Safe pattern using sqlx query_as with bind parameters:

use sqlx::FromRow;

#[derive(FromRow)]
struct User {
    id: i32,
    email: String,
}

async fn get_user_by_email(
    pool: &sqlx::PgPool,
    email: &str,
) -> Result<User, sqlx::Error> {
    sqlx::query_as("SELECT id, email FROM users WHERE email = $1")
        .bind(email)
        .fetch_one(pool)
        .await
}

The .bind(email) method ensures the value is sent separately from the query structure, making SQL injection infeasible. This pattern works across PostgreSQL, MySQL, and SQLite with sqlx.

Safe pattern using sqlx query with explicit mapping:

async fn get_user_by_id(
    pool: &sqlx::PgPool,
    user_id: i32,
) -> Result<User, sqlx::Error> {
    sqlx::query("SELECT id, email FROM users WHERE id = $1")
        .bind(user_id)
        .try_map(|row: sqlx::postgres::PgRow| {
            Ok(User {
                id: row.try_get("id")?,
                email: row.try_get("email")?,
            })
        })
        .fetch_one(pool)
        .await
}

For applications using extractors, ensure that query parameters are validated and bound rather than interpolated. The GitHub Action can enforce this by failing builds if static analysis detects string-based SQL construction in route handlers. Continuous monitoring via the Pro plan helps catch regressions that reintroduce injection risks after refactors.