Phishing Api Keys in Axum with Api Keys

In Axum applications that manage authentication via static Api Keys, developers sometimes expose those keys through insecure logging, debug endpoints, or predictable URL patterns. An attacker can combine social engineering with endpoint discovery to phish Api Keys by tricking a maintainer into visiting a malicious route or opening a crafted link that captures key material. For example, if an Axum app defines a catch-all route like /api/:key for convenience, a phishing email might direct a user to https://example.com/api/phishing_key while the attacker observes server logs or error responses that reveal valid keys. This becomes more impactful when the Api Keys are embedded in JavaScript bundles or documentation that can be scraped by automated tools. Because Axum does not enforce key rotation or binding to specific scopes by default, compromised keys can be reused across services, enabling lateral movement. The risk is compounded when the same Api Keys are used in multiple environments, such as staging and production, since a phishing attack against a lower-privilege service can yield keys that work elsewhere. MiddleBrick scans detect these exposure patterns by correlating unauthenticated endpoint behavior with known leakage vectors, identifying routes that inadvertently echo key material and flagging missing key-binding controls.

To reduce phishing risk for Api Keys in Axum, rotate keys immediately upon suspicion and enforce strict validation and scoping. Use typed extractor patterns that validate key format and origin instead of relying on raw path parameters. Below are concrete examples that demonstrate secure handling.

1. Typed extractor with format validation

Define a dedicated extractor that checks key structure and rejects malformed or suspicious values before they reach handlers.

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

struct ApiKey(String);

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

    async fn from_request(req: Request<S>) -> Result<Self, Self::Rejection> {
        let key = req.headers()
            .get("X-API-Key")
            .and_then(|v| v.to_str().ok())
            .filter(|k| is_valid_key_format(*k))
            .ok_or((http::StatusCode::UNAUTHORIZED, "Invalid or missing API key".to_string()))?;
        Ok(ApiKey(key.to_string()))
    }
}

fn is_valid_key_format(key: &str) -> bool {
    // Enforce a strict pattern, e.g., 32 hex characters
    key.len() == 32 && key.chars().all(|c| c.is_ascii_hexdigit())
}

use axum::{Extension, routing::get, Router};
use std::sync::Arc;

struct AppState {
    valid_key: String,
}

async fn health() -> String {
    "OK".to_string()
}

async fn admin(Extension(state): Extension<Arc<AppState>>, ApiKey(key): ApiKey) -> String {
    // Compare without exposing key in logs
    if constant_time_eq::constant_time_eq(key.as_bytes(), state.valid_key.as_bytes()) {
        "Authorized".to_string()
    } else {
        "Forbidden".to_string()
    }
}

fn constant_time_eq(a: &str, b: &str) -> bool {
    subtle::ConstantTimeEq::ct_eq(a.as_bytes(), b.as_bytes()).into()
}

#[tokio::main]
async fn main() {
    let state = Arc::new(AppState { valid_key: "0123456789abcdef0123456789abcdef".to_string() });
    let app = Router::new()
        .route("/health", get(health))
        .route("/admin", get(admin))
        .layer(Extension(state));
    axum::Server::bind("0.0.0.0:3000".parse().unwrap())
        .serve(app.into_make_service())
        .await
        .unwrap();
}

use axum::async_trait;
use std::collections::HashSet;

struct ScopedKey {
    key: String,
    allowed_routes: HashSet<String>,
}

impl ScopedKey {
    fn can_access(&self, route: &str) -> bool {
        self.allowed_routes.contains(route)
    }
}

async fn scoped_handler(ScopedKey(key): ScopedKey) -> String {
    "Scoped access granted".to_string()
}