Session Fixation in Actix with Basic Auth

Session fixation in Actix when Basic Auth is used arises because the server may issue a session identifier before authentication and then link that same session to a verified identity after credentials are validated. If the session ID is not rotated after successful Basic Auth authentication, an attacker who can predict or set a session ID can force a victim to authenticate under that known session, effectively hijacking the authenticated session.

Basic Auth transmits credentials on every request encoded in Base64 (not encrypted), so interception (e.g., via passive network sniffing or insecure logging) can expose credentials. When combined with a static or predictable session ID, this creates a chain: the attacker captures a victim’s session ID (e.g., from a URL or insecure cookie), waits for the victim to authenticate with Basic Auth, and then uses the now-authenticated session to impersonate the victim. Because Actix applications often manage sessions via cookies or custom headers, failure to reissue identifiers on authentication enables this fixation path.

In an API context, session fixation with Basic Auth can also manifest when a token or API key is issued before proper scope verification, and that same token is reused post-authentication. MiddleBrick’s checks for BOLA/IDOR and Authentication are designed to surface such weaknesses by correlating unauthenticated session behaviors with authenticated responses.

Remediation focuses on ensuring session identifiers are established only after successful authentication and are rotated afterward. For Actix web applications, this means deferring session creation until after Basic Auth credentials are validated and explicitly regenerating any session state.

Example: secure Actix handler using Basic Auth with session rotation after authentication. This example uses the actix-web and actix-identity crates, validating credentials before establishing identity and clearing any pre-auth session cookie.

use actix_web::{web, HttpRequest, HttpResponse, Result};
use actix_identity::{Identity, CookieIdentityPolicy, IdentityService};

async fn login(
    req: HttpRequest,
    id: Identity,
    credentials: web::Json,
) -> Result {
    // Validate Basic Auth credentials (example: simple comparison)
    if credentials.username == "legitimate_user" && credentials.password == "correct_hashed_password" {
        // Clear any pre-authentication session identifier
        id.forget();
        // Establish a fresh identity only after successful auth
        id.remember("user_id_123".to_string());
        return Ok(HttpResponse::Ok().body("Authenticated"));
    }
    id.forget();
    Ok(HttpResponse::Unauthorized().body("Invalid credentials"))
}

// Ensure IdentityService is configured with secure policies in main
fn configure_identity_service(cfg: &mut web::ServiceConfig) {
    cfg.service(
        IdentityService::new(
            CookieIdentityPolicy::new(&[0; 32]) // secure key
                .name("auth_session")
                .secure(true), // set to true in production (HTTPS)
        )
    );
}

Key practices to prevent fixation with Basic Auth:

• Never create or accept a session token before validating credentials.
• Always call an identity reset operation (e.g., forget in Actix Identity) prior to establishing a new authenticated identity.
• Ensure session cookies are HttpOnly, Secure, and have SameSite attributes aligned with your threat model.
• Treat Basic Auth as a bearer credential for each request; avoid storing it in logs or server-side session state without hashing.