Privilege Escalation in Axum with Api Keys

In Axum, privilege escalation via API keys commonly occurs when key validation is performed incompletely or when key-to-role mappings are handled in user-controlled code without strict enforcement. Axum is an ergonomic web framework for Rust, and while it does not ship built-in authorization, developers often implement API key checks as middleware or via extractor patterns. If these checks are inconsistent—for example, failing to reject requests with a missing or malformed key, or incorrectly elevating a key with limited scopes to an admin role—attackers can escalate privileges.

A typical vulnerable pattern is binding roles or permissions from the key metadata (e.g., claims or a lookup map) and then passing that role directly into downstream authorization decisions without re-verifying scope or intent. If an attacker can influence the request path (e.g., via Host header poisoning or route prefix confusion), they might cause the application to treat a read-only key as having write or administrative rights. This maps to BOLA/IDOR and BFLA/Privilege Escalation checks in middleBrick’s 12 parallel scans, which test whether a subject can access or modify resources belonging to another subject or exceed their assigned privileges.

Consider an Axum handler that retrieves a key, determines a user role, and then decides authorization inline. If the role is derived from a JWT claim or a database lookup tied to that key, but the handler does not re-validate the key on each sensitive operation, an attacker who obtains or guesses a low-privilege key might craft requests that invoke admin endpoints. For example, a key issued for read-only analytics could be used to trigger a deletion endpoint if the endpoint relies solely on the initial role resolution rather than a per-request privilege check. middleBrick’s LLM/AI Security checks do not apply here, but the scan’s BFLA/Privilege Escalation and Property Authorization tests are designed to detect such inconsistencies in unauthenticated or low-auth contexts.

Real-world parallels include misconfigured OAuth scopes or overly permissive IAM policies, where a token with read access is accepted by an endpoint that assumes write capability is gated elsewhere. In Axum, this can surface when route guards or tower layers assume a key’s permissions without reconfirming them at the handler level. An attacker might also exploit path-based confusion or middleware ordering to bypass intended restrictions, effectively escalating from a limited key to operations intended for higher-privilege keys. These patterns are detectable through structured scanning that cross-references spec definitions with runtime behavior, ensuring that each endpoint enforces key-bound checks consistently.

To remediate privilege escalation risks tied to API keys in Axum, enforce strict validation and scoping on every request, avoid implicit elevation, and ensure authorization is re-evaluated per operation. Below are concrete patterns and code examples that demonstrate secure handling.

1. Centralized key extraction and validation with tower middleware

Implement a tower layer that extracts and validates API keys before requests reach your handlers. This ensures consistent enforcement and prevents handlers from accidentally trusting unchecked claims.

use axum::async_trait;
use axum::extract::{FromRequest, Request};
use axum::http::StatusCode;
use std::convert::Infallible;
use std::sync::Arc;

#[derive(Clone)]
struct ApiKeyValidator {
    valid_keys: Arc>,
}

#[derive(Clone)]
struct ApiKeyInfo {
    key_id: String,
    scopes: Vec,
}

#[derive(Debug)]
enum KeyError {
    MissingKey,
    InvalidKey,
}\n
impl std::fmt::Display for KeyError {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        write!(f, "{:?}", self)
    }
}

impl std::error::Error for KeyError {}

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

    async fn from_request(req: Request, _: &S) -> Result {
        let validator = req.extensions()
            .get::()
            .ok_or_else(|| (StatusCode::INTERNAL_SERVER_ERROR, "Missing validator".to_string()))?;

        let key = req.headers()
            .get("x-api-key")
            .and_then(|v| v.to_str().ok())
            .ok_or_else(|| (StatusCode::UNAUTHORIZED, "Missing API key".to_string()))?;

        validator.valid_keys.get(key)
            .cloned()
            .ok_or_else(|| (StatusCode::UNAUTHORIZED, "Invalid API key".to_string()))
    }
}

async fn check_scope(required: &str, info: &ApiKeyInfo) -> Result<(), (StatusCode, String)> {
    if info.scopes.contains(&required.to_string()) {
        Ok(())
    } else {
        Err((StatusCode::FORBIDDEN, "Insufficient scope".to_string()))
    }
}

// In your router setup:
// let validator = ApiKeyValidator { valid_keys: Arc::new(preloaded_keys) };
// let app = Router::new()
//     .layer(TowerLayer::new())
//     .with_state(validator)
//     .route("/admin", post(admin_handler));

async fn admin_handler(
    ApiKeyInfo { scopes, .. }: ApiKeyInfo,
    payload: Json,
) -> Result, (StatusCode, String)> {
    check_scope("admin:write", &ApiKeyInfo { scopes, .. })
        .map_err(|e| e)?;
    // Perform admin action
    Ok(Json(AdminResponse { ok: true }))
}

// Inside ApiKeyValidator::from_request:
let info = validator.valid_keys.get(key)
    .ok_or_else(|| (StatusCode::UNAUTHORIZED, "Invalid API key".to_string()))?;
if info.scopes.is_empty() {
    return Err((StatusCode::FORBIDDEN, "Key has no scopes".to_string()));
}

// Example rejection handler to normalize responses
async fn rejection_handler(err: Rejection) -> Result {
    let (status, message) = if err.find::().is_some() {
        (StatusCode::UNAUTHORIZED, "Unauthorized".to_string())
    } else if let Some((status, msg)) = err.downcast_ref::<(StatusCode, String)>() {
        (*status, msg.clone())
    } else {
        (StatusCode::INTERNAL_SERVER_ERROR, "Internal error".to_string())
    };
    Ok((status, message).into_response())
}