Session Fixation in Axum with Dynamodb

Session fixation occurs when an application assigns a user a session identifier before authentication and does not regenerate that identifier after login. In an Axum application using DynamoDB as the session store, this pattern can expose a predictable or attacker-controlled session token that maps directly to a user identity in DynamoDB.

Axum does not prescribe session handling; developers typically manage sessions via cookies and a backend store. If the application sets a session cookie before login and later uses that same session key to look up user data in DynamoDB, an attacker can set a known session ID on the victim’s browser (for example, by sending a link with session_id=attacker_controlled). After the victim authenticates, the attacker can use the same session ID to access the victim’s authenticated session because the DynamoDB item key corresponds to the fixed session identifier.

DynamoDB stores session state by key; if the key is predictable (e.g., based on user input or a non-cryptographic random value), it becomes easier for an attacker to guess or fix the session identifier. Even with strong access controls on DynamoDB, the flaw is at the application layer: failing to rotate the session identifier after authentication means the pre-authentication token remains valid post-login. Common misconfigurations include using sequential keys, non-random strings, or failing to bind the session to the authenticated user’s identity and a server-side validation step.

Consider an endpoint that first creates a session record in DynamoDB with a client-provided or weakly generated token:

use axum::{routing::get, Router};
use aws_sdk_dynamodb::Client as DynamoClient;

async fn create_session(
    user_id: String,
    session_token: String,
    dynamodb: &DynamoClient,
) -> Result<(), aws_sdk_dynamodb::types::SdkError> {
    dynamodb
        .put_item()
        .table_name("sessions")
        .item("session_token", aws_sdk_dynamodb::types::AttributeValue::S(session_token))
        .item("user_id", aws_sdk_dynamodb::types::AttributeValue::S(user_id))
        .item("expires_at", aws_sdk_dynamodb::types::AttributeValue::N(format!(SystemTime::now()
            .duration_since(UNIX_EPOCH)
            .unwrap()
            .as_secs() + 3600)))
        .send()
        .await?;
    Ok(())
}

If the session_token is supplied by the client or derived from a non-random source, an attacker can fix the token before authentication. After login, the DynamoDB item keyed by that token now maps to an authenticated user, enabling the attacker to hijack the session.

To detect this pattern during a scan, middleBrick tests unauthenticated endpoints that set or accept session identifiers and checks whether authentication changes the token binding. Findings include references to OWASP API Top 10 A07:2021 (Identification and Authentication Failures) and remediation guidance to rotate session identifiers and bind them securely to authenticated user records in DynamoDB.

Remediation centers on ensuring that session identifiers are cryptographically random, rotated after authentication, and consistently bound to the authenticated user in DynamoDB. Avoid accepting session tokens from the client for authenticated operations; instead, derive the token server-side and enforce strict key design in DynamoDB.

Use a cryptographically secure random generator to create session tokens, and upon successful authentication, create a new DynamoDB item with a new token while invalidating the pre-authentication token. Below is an example of secure session creation in Axum with DynamoDB:

use axum::{routing::post, Form, Router};
use aws_sdk_dynamodb::Client as DynamoClient;
use rand::{distributions::Alphanumeric, Rng};
use std::time::{SystemTime, UNIX_EPOCH};

async fn login_user(
    Form(params): Form,
    dynamodb: &DynamoClient,
) -> Result {
    // Validate credentials against your user store
    if !validate_credentials(¶ms.username, ¶ms.password).await {
        return Err("invalid credentials");
    }

    // Generate a cryptographically random session token
    let session_token: String = rand::thread_rng()
        .sample_iter(&Alphanumeric)
        .take(32)
        .map(char::from)
        .collect();

    let expires_at = SystemTime::now()
        .duration_since(UNIX_EPOCH)
        .unwrap()
        .as_secs() + 3600;

    // Store session keyed by the server-generated token in DynamoDB
    dynamodb
        .put_item()
        .table_name("sessions")
        .item("session_token", aws_sdk_dynamodb::types::AttributeValue::S(session_token.clone()))
        .item("user_id", aws_sdk_dynamodb::types::AttributeValue::S(params.username))
        .item("expires_at", aws_sdk_dynamodb::types::AttributeValue::N(expires_at.to_string()))
        .send()
        .await
        .map_err(|_| "failed to create session")?;

    // Invalidate any prior session tokens for this user if applicable
    // delete_previous_sessions_for_user(&dynamodb, ¶ms.username).await;

    Ok(session_token)
}

On each request, validate the session token by retrieving the item from DynamoDB using the token as the key. Ensure that the token is transmitted only over HTTPS and set HttpOnly, Secure, and SameSite attributes on the cookie. Do not allow the client to dictate the session key used for authenticated DynamoDB lookups.

For continuous protection, the Pro plan’s GitHub Action can be added to your CI/CD pipeline to fail builds if risk scores exceed your threshold, while the dashboard lets you track session-related findings over time. The MCP Server enables you to scan APIs directly from your AI coding assistant, helping to catch insecure session patterns before deployment.