Injection Flaws in Axum with Api Keys

Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. In Axum, combining Api Key validation with parameter handling can inadvertently expose injection surfaces if keys are used to influence routing, database queries, or external HTTP calls. A common pattern is reading an Api Key from headers and passing it directly into a SQL string or a dynamic endpoint path without validation or parameterization. For example, concatenating a key-derived identifier into a query string creates SQL injection risk, while using the key to construct URLs can lead to SSRF.

Axum middleware that extracts Api Keys and uses them to select downstream targets can magnify injection issues. If an Api Key is treated as an identifier for tenant or service routing, and that identifier is reflected into logs, error messages, or used to build dynamic queries, attackers may leverage injection techniques (e.g., SQLi, command injection) through the key value. Even though Api Keys are typically opaque strings, insufficient input validation on their usage context allows malicious payloads to be interpreted as code or commands.

Consider an endpoint that accepts an Api Key and a resource ID, then uses both to query a database. If the Api Key is used to select a database schema or table name, and the resource ID is interpolated without parameterization, the combination enables injection. Real-world attack patterns include SQL injection (CVE-2023-23397-style payloads via crafted headers) and command injection when keys are passed to shell utilities. The risk is compounded when logging or error handling inadvertently echoes the key or constructed query, providing attackers with feedback to refine injection attempts.

Secure handling of Api Keys in Axum requires strict separation between authentication and business logic, along with parameterization of all dynamic values. Treat Api Keys as opaque credentials for authentication only, never as data used in queries or command construction. Use middleware to validate the key against a trusted store, then attach a normalized principal to the request extensions for downstream handlers.

Below is a safe Axum example that validates an Api Key via middleware and uses extensions to pass authorization context without injecting the key into queries:

use axum::{{
    async_trait,
    extract::{FromRequest, Request},
    http::Request as HttpRequest,
    middleware, Extension, Router,
}};
use std::{net::SocketAddr, sync::Arc};

struct ApiKeyValidator {
    valid_keys: Arc<std::collections::HashSet<String>>,
}

#[async_trait]
impl FromRequest<S> for String
where
    S: Send + Sync,
{
    type Rejection = (axum::http::StatusCode, &'static str);

    async fn from_request(req: Request, _state: &S) -> Result<Self, Self::Rejection> {
        let headers = req.headers();
        match headers.get("X-API-KEY") {
            Some(h) => {
                let key = h.to_str().map_err(|_| (axum::http::StatusCode::UNAUTHORIZED, "Invalid key format"))?;
                // Perform constant-time lookup in production
                if VALID_KEYS.contains(key) {
                    Ok(key.to_string())
                } else {
                    Err((axum::http::StatusCode::UNAUTHORIZED, "Invalid API key"))
                }
            }
            None => Err((axum::http::StatusCode::UNAUTHORIZED, "Missing API key")),
        }
    }
}

// Usage in a handler: the key is validated but not used in SQL strings.
async fn get_resource(Extension(key): Extension<String>, Query(params): Query<ResourceParams>) -> String {
    // Use key only for authorization checks or to fetch tenant-specific data via safe parameterized queries.
    format!("Access granted for key: {}", key)
}

#[tokio::main]
async fn main() {
    let valid_keys: std::collections::HashSet<String> = ["s3cr3t_k3y_123".to_string()].into_iter().collect();
    let validator = ApiKeyValidator { valid_keys: Arc::new(valid_keys) };

    let app = Router::new()
        .route("/resource", axum::routing::get(get_resource))
        .layer(middleware::from_fn_with_state(validator, |state, req, next| async move {
            let key = ApiKeyValidator::from_request(req, &()).await?;
            req.extensions_mut().insert(key);
            next.run(req).await
        }));

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

use sqlx::postgres::PgPool;

async fn fetch_resource(pool: &PgPool, api_key: &str, resource_id: i32) -> Result<(), sqlx::Error> {
    // Safe: parameterized query, api_key used only for row-level security or tenant identification.
    let row: (String,) = sqlx::query_as("SELECT name FROM resources WHERE id = $1 AND tenant_key = $2")
        .bind(resource_id)
        .bind(api_key)
        .fetch_one(pool)
        .await?;
    Ok(())
}