Session Fixation in Axum with Basic Auth

Session fixation occurs when an application assigns a user a session identifier before authentication and does not issue a new identifier after authentication. In Axum, if your application creates a session token or cookie before validating credentials, an attacker can set or predict that token and force a victim to authenticate under it. Combining this pattern with HTTP Basic Auth amplifies the risk because the credentials are sent on every request, making it easier for an attacker to observe or replay them while relying on the fixed session.

Basic Auth itself does not manage sessions; it is a stateless challenge-response mechanism where the client sends an Authorization header on each request. However, when you implement session-like behavior on top of Basic Auth (for example, by issuing a JWT, a session cookie, or server-side state after successful authentication), Axum code that reuses an existing identifier becomes vulnerable. An attacker can craft a URL or host a page that sets a known cookie path or header, then trick a logged-in user into making a request where Axum treats the reused token as proof of identity.

In Axum, a typical misstep is to authenticate a user once, store user data in a session store or issue a long-lived token, and then skip re-authentication for privileged actions. Because Basic Auth sends credentials in every request, an attacker can capture the credentials via network sniffing or logs and then reuse them, while the fixed session identifier allows the attacker to maintain access even if the password changes. The vulnerability is not in Basic Auth itself but in how Axum handles session state post-authentication and how you scope authorization checks.

To detect this with middleware like middleBrick, note that the scanner’s Authorization and BOLA/IDOR checks look for endpoints that authenticate but do not rotate or validate session context after login. If your Axum routes authenticate via Basic Auth and then rely on a static session key without verifying freshness or binding the session to the authenticated identity, the scan can flag this as a broken access control pattern that mirrors session fixation risks.

Remediation focuses on ensuring that any session token, cookie, or JWT is issued only after successful authentication and is tied to the authenticated identity. Avoid accepting session identifiers that were set before authentication, and enforce per-request validation of credentials and permissions. middleBrick’s findings can guide you to endpoints where authentication headers are present but session handling is inconsistent.

Secure Axum applications using Basic Auth should authenticate on each request and avoid storing pre-authentication session identifiers. After validating credentials, issue a new session token or update server-side state, and ensure that sensitive operations require re-authentication or fresh validation.

Example: Basic Auth extraction and validation in Axum without session fixation.

use axum::{
    async_trait,
    extract::{Request, State},
    http::HeaderValue,
    response::IntoResponse,
};
use std::net::SocketAddr;
use tower_http::services::ServeDir;

struct AuthUser {
    username: String,
    password_hash: String, // store bcrypt/argon2 hash
}

async fn validate_basic_auth(
    header: &HeaderValue,
    users_db: &std::collections::HashMap,
) -> Option {
    let header = header.to_str().ok()?;
    if !header.starts_with("Basic ") {
        return None;
    }
    let encoded = &header["Basic ".len()..];
    let decoded = base64::decode(encoded).ok()?;
    let credentials = String::from_utf8(decoded).ok()?;
    let parts: Vec<&str> = credentials.splitn(2, ':').collect();
    if parts.len() != 2 {
        return None;
    }
    let (username, password) = (parts[0], parts[1]);
    let user = users_db.get(username)?;
    // Use a constant-time password verification in production
    if verify_password(password, &user.password_hash) {
        Some(user.clone())
    } else {
        None
    }
}

fn verify_password(_password: &str, _hash: &str) -> bool {
    // Replace with proper password hashing verification
    true
}

async fn handler(
    State(users_db): State>>,
    request: Request,
) -> impl IntoResponse {
    let headers = request.headers();
    match validate_basic_auth(headers.get(&"authorization").unwrap_or(&HeaderValue::from_static("")), &users_db) {
        Some(user) => format!("Authenticated as: {}", user.username).into_response(),
        None => (axum::http::StatusCode::UNAUTHORIZED, "Invalid credentials").into_response(),
    }
}

#[tokio::main]
async fn main() {
    let mut users_db = std::collections::HashMap::new();
    // Populate users_db with hashed passwords
    let users_db = std::sync::Arc::new(users_db);
    let app = axum::Router::new().route("/secure", axum::routing::get(handler)).with_state(users_db);
    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr).serve(app.into_make_service()).await.unwrap();
}

Key practices to prevent session fixation with Basic Auth in Axum:

Do not accept a session token or cookie set before validating Basic Auth credentials.
After validating credentials, create a new session token or update server-side session state rather than reusing an existing identifier.
Bind the session to the authenticated identity (e.g., username and a server-side random nonce) and include checks that the session matches the current credentials on each sensitive operation.
Use HTTPS to prevent credential leakage; Basic Auth sends credentials on every request and must be protected in transit.
Consider rate-limiting and replay protections because reused credentials increase exposure if session identifiers are static.

middleBrick scans can highlight endpoints where authentication headers are present but session handling lacks rotation or binding, helping you locate areas where session fixation may occur.