Cross Site Request Forgery in Axum with Dynamodb

Cross Site Request Forgery (CSRF) in an Axum application that uses DynamoDB can emerge when state-changing HTTP methods (POST, PUT, DELETE) rely only on cookies for session identity without anti-CSRF tokens or additional verification. In such a setup, an attacker can craft a malicious site that triggers requests from an authenticated browser to your Axum endpoints, and those requests may directly call DynamoDB operations via your service code.

Consider an Axum handler that deletes a DynamoDB item based on an identifier passed in a request parameter or body. If the handler trusts the session cookie and does not validate a CSRF token, an attacker can lure a logged-in user to a page like <img src="https://your-app.example.com/users/delete?user_id=attacker_id" />. The browser automatically includes cookies, the Axum route executes a DynamoDB DeleteItem call, and the attacker’s action impacts the victim’s account. This risk is not inherent to DynamoDB but arises from the combination of cookie-based authentication in Axum and state-changing operations that do not verify intent beyond the session.

Another scenario involves forms that perform writes to DynamoDB. Without a synchronizer token pattern (e.g., a CSRF token embedded in forms and validated server-side), an attacker can build a form on a malicious site that mirrors the expected fields and submits it to your Axum endpoints. Because Axum does not enforce CSRF protection by default, developers must explicitly add defenses. The DynamoDB calls themselves are neutral; the vulnerability is in the request handling flow where identity proof is insufficient.

CSRF also intersects with security checks such as Authentication and BOLA/IDOR in middleBrick scans. For example, an unauthenticated scan might not detect missing CSRF protections, but authenticated scans or manual review can reveal routes that perform sensitive DynamoDB actions without anti-CSRF measures. Findings often include missing origin/referrer checks, lack of same-site cookie attributes, and absence of per-request token validation.

To understand the exposure, compare routes that use signed session cookies only versus those that include CSRF tokens and strict cookie policies. The former is more susceptible to CSRF when performing DynamoDB writes; the latter reduces risk by requiring a token that an attacker cannot read or predict. MiddleBrick’s Authentication and BOLA/IDOR checks help highlight where identity assumptions are too weak, prompting deeper review of CSRF readiness.

Remediation focuses on ensuring each state-changing request is intentional and tied to the authenticated user. Implement anti-CSRF tokens, enforce strict cookie attributes, and validate ownership of resources before executing DynamoDB operations. Below are concrete Axum examples that integrate these practices while interacting with DynamoDB.

1. Use the tower-csrf crate or a custom extractor to validate CSRF tokens for mutating routes. Store the token in a same-site, secure cookie and require it for POST/PUT/DELETE operations.

use axum::{routing::post, Router, extract::State, http::StatusCode};
use csrf::CsrfToken;
use serde::Deserialize;
use aws_sdk_dynamodb::Client;

struct AppState {
    csrf_secret: [u8; 32],
    dynamodb: Client,
}

async fn delete_user(
    State(state): State<AppState>,
    CsrfToken(token): CsrfToken,
    // Extract a user_id from a safe source, e.g., path or a validated JSON body
    user_id: String,
) -> Result<(), (StatusCode, String)> {
    // Verify token (this is conceptual; use a robust CSRF library)
    if !validate_csrf(&state.csrf_secret, &token) {
        return Err((StatusCode::FORBIDDEN, "Invalid CSRF token".into()));
    }

    // Proceed with DynamoDB delete only after CSRF validation
    let table_name = "users";
    let outcome = state.dynamodb
        .delete_item()
        .table_name(table_name)
        .key("user_id", aws_sdk_dynamodb::types::AttributeValue::S(user_id))
        .send()
        .await;

    match outcome {
        Ok(_) => Ok(()),
        Err(e) => Err((StatusCode::INTERNAL_SERVER_ERROR, format!("DynamoDB error: {}", e))),
    }
}

fn validate_csrf(secret: &[u8; 32], token: &str) -> bool {
    // In practice, use a crate such as `cookie-csrf` or similar
    // Placeholder for constant-time comparison
    token.len() == 32
}

fn main() {
    let config = aws_config::load_from_env().await;
    let client = aws_sdk_dynamodb::Client::new(&config);
    let state = AppState {
        csrf_secret: [0u8; 32], // derive a real secret in production
        dynamodb: client,
    };

    let app = Router::new()
        .route("/users/delete", post(delete_user))
        .with_state(state);

    // axum::Server::bind(&"0.0.0.0:3000".parse().unwrap()).serve(app.into_make_service()).await.unwrap();
}

2. Enforce secure cookie attributes and consider a synchronizer token pattern for forms. Set SameSite=Strict or Lax, Secure, and HttpOnly where appropriate, and include a CSRF token in forms that is validated on submission.

use axum::response::Html;
use rand::Rng;

async fn show_form() -> Html<String> {
    let token: String = rand::thread_rng().sample_iter(&rand::distributions::Alphanumeric).take(32).map(char::from).collect();
    // Store token in session or a signed cookie for validation on submit
    Html(format!(r#"<form method="POST">
        <input type="hidden" name="csrf_token" value="{}" />
        <button type="submit">Delete</button>
    </form>"#, token))
}

3. Before calling DynamoDB, validate that the authenticated user is authorized to act on the target resource (BOLA/IDOR mitigation). Do not rely solely on the session identity; ensure the item’s ownership matches the user’s identity.

async fn delete_own_user(
    State(state): State<AppState>,
    user_id: String, // from path, already validated safe
    session_user: String, // from session/cookie, trusted but verified server-side
) -> Result<(), (StatusCode, String)> {
    // Fetch the item first to confirm ownership
    let outcome = state.dynamodb
        .get_item()
        .table_name("users")
        .key("user_id", aws_sdk_dynamodb::types::AttributeValue::S(user_id.clone()))
        .send()
        .await;

    let item = match outcome {
        Ok(o) => o.item.ok_or_else(|| (StatusCode::NOT_FOUND, "User not found".into()))?,
        Err(e) => return Err((StatusCode::INTERNAL_SERVER_ERROR, format!("DynamoDB error: {}", e))),
    };

    let owner = item.get("owner").and_then(|v| v.as_s()).ok_or_else(|| (StatusCode::FORBIDDEN, "Invalid item format".into()))?;
    if owner != session_user {
        return Err((StatusCode::FORBIDDEN, "Not authorized".into()));
    }

    state.dynamodb
        .delete_item()
        .table_name("users")
        .key("user_id", aws_sdk_dynamodb::types::AttributeValue::S(user_id))
        .send()
        .await
        .map(|_| ())
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, format!("DynamoDB error: {}", e)))
}

These examples emphasize that remediation is not about changing DynamoDB usage but ensuring requests are authenticated, authorized, and protected against CSRF. Combine these patterns with middleBrick’s Authentication, BOLA/IDOR, and BFLA/Privilege Escalation checks to verify that your API surface enforces strict identity validation and least-privilege operations.