Vulnerable Components in Axum with Api Keys

In Axum, combining API key validation with common application components can introduce security risks when implementation details deviate from secure patterns. API keys are often passed via HTTP headers, query parameters, or cookies. When these keys are handled inconsistently across middleware, route handlers, and data flows, they can expose the unauthenticated attack surface that middleBrick scans for under the Authentication and BFLA/Privilege Escalation checks.

A typical vulnerable pattern is conditional key checking where some routes enforce key validation while others do not, creating privilege escalation opportunities. For example, if an Axum application applies key validation only at the router level for a subset of paths and relies on runtime checks within handlers, an attacker may exploit missing authorization on related endpoints. This misalignment can lead to IDOR-like scenarios where access control depends on the presence of a key but the key is not validated uniformly across all operations.

Another risky component is the storage and logging of API keys. If keys are logged accidentally, exposed through debug endpoints, or stored in plaintext in configuration structures, the Data Exposure and Unsafe Consumption checks may flag findings. In Axum, this can occur when request extensions or tracing layers forward headers indiscriminately, or when developers use the same key for multiple services without rotation, increasing the impact of a leaked key.

Middleware composition also plays a role. If API key validation middleware is placed after body parsing or error handling middleware, an attacker might trigger errors that bypass validation or cause key leakage through verbose error messages. The scanner tests such paths by probing unauthenticated endpoints and inspecting whether responses reveal whether a key is required or how it is processed, aligning with the Authentication and Input Validation checks.

Finally, dynamic key handling—such as deriving keys from user input or using keys to index into data stores without strict authorization—can lead to BOLA/IDOR findings. Even when keys are validated, the application may still return resources that the key’s scope should not permit. middleBrick’s unauthenticated scan detects whether key presence alone grants unintended access, highlighting gaps in how Axum route guards and request guards interact with business logic.

To remediate API key issues in Axum, enforce uniform validation before routing and within handlers, and avoid ad-hoc checks. Use extractor patterns consistently and ensure middleware ordering does not expose validation bypass paths. Below are concrete, working examples.

1. Consistent key validation via an extractor used across all protected routes:

use axum::async_trait;
use axum::extract::{FromRequest, Request};
use axum::http::StatusCode;
use std::future::Future;
use std::pin::Pin;

#[derive(Debug, Clone)]
struct ApiKey(String);

#[async_trait]
impl FromRequest<S> for ApiKey
where
    S: Send + Sync,
{
    type Rejection = (StatusCode, String);

    async fn from_request(req: Request, _state: &S) -> Result<Self, Self::Rejection> {
        let key = req.headers()
            .get("X-API-Key")
            .and_then(|v| v.to_str().ok())
            .filter(|&k| k == "SECRET_KEY_123"); // replace with secure storage/validation
        match key {
            Some(k) => Ok(ApiKey(k.to_string())),
            None => Err((StatusCode::UNAUTHORIZED, "Missing or invalid API key".to_string())),
        }
    }
}

// Usage in routes
async fn public_handler() -> String {
    "public data".to_string()
}

async fn private_handler(_key: ApiKey) -> String {
    "protected data".to_string()
}

// Build your Router with extractors on each route that requires protection
let app = Router::new()
    .route("/public", get(public_handler))
    .route("/private", get(private_handler));

use axum::extract::Extension;
use axum::http::StatusCode;
use std::sync::Arc;

struct KeyGuard {
    key: String,
    allowed_resources: Vec<String>, // e.g., resource IDs the key can access
}

async fn validate_key(
    Extension(state): Extension<Arc<AppState>>,
    key: Result<ApiKey, (StatusCode, String)>,
    resource_id: String,
) -> Result<KeyGuard, (StatusCode, String)> {
    let key = key.map_err(|(_, msg)| (StatusCode::UNAUTHORIZED, msg))?;
    let state = state.keys.get(&key.0).ok_or_else(|| {
        (StatusCode::FORBIDDEN, "Key not found in registry".to_string())
    })?;
    if state.allowed_resources.contains(&resource_id) {
        Ok(KeyGuard {
            key: key.0,
            allowed_resources: state.allowed_resources.clone(),
        })
    } else {
        Err((StatusCode::FORBIDDEN, "Insufficient scope for resource".to_string()))
    }
}

// In a handler:
async fn get_resource(
    Extension(state): Extension<Arc<AppState>>,
    ApiKey(key): ApiKey,
    Path(resource_id): Path<String>,
) -> Result<impl IntoResponse, (StatusCode, String)> {
    let _guard = validate_key(Extension(state), Ok(ApiKey(key)), resource_id).await?;
    // proceed safely
    Ok("resource data")
}

let app = Router::new()
    .layer(Extension(state.clone()))
    .route("/public", get(public_handler))
    .route("/admin", get(admin_handler))
    .route("/resource/:id", get(get_resource));

// Place logging and error handling after routing decisions
let app = app.into_make_service_with_connect_info::<SocketAddr>()
    .map_err(|err| {
        // Avoid leaking validation details in errors
        warn!("Request error: {:?}", err);
        (StatusCode::INTERNAL_SERVER_ERROR, "An error occurred".to_string())
    });

// Configure tracing to exclude sensitive headers
use tracing_subscriber::filter::LevelFilter;
use tracing_subscriber::layer::SubscriberExt;
use tracing_subscriber::util::SubscriberInitExt;

let subscriber = tracing_subscriber::fmt()
    .with_filter(LevelFilter::INFO)
    .with_env_filter("axum_api=info")
    .finish();

axum::Extension::layer().with(subscriber);
// Ensure headers like X-API-Key are not included in logs