Cross Site Request Forgery in Axum with Mongodb

Cross Site Request Forgery (CSRF) in an Axum application that uses MongoDB for state and session storage arises when an authenticated user’s session can be tricked into issuing unintended writes to the database via forged requests. Axum does not include built-in CSRF protections, so developers must implement mitigations explicitly. When Axum endpoints rely on cookies for session tokens or authentication (for example, a session ID stored in a cookie and a MongoDB collection mapping sessions to users), an attacker can craft an HTML form or JavaScript request on a malicious site that targets those endpoints. Because the browser automatically includes cookies for the target domain, the request may appear legitimate to the server even though it originated from an untrusted origin.

With MongoDB as the backend, the risk materializes when the endpoint performs state-changing operations such as updates or deletions based on identifiers that are only validated via cookies or headers. For instance, an endpoint like /api/users/{user_id}/preferences that accepts a PATCH or POST without a same-site cookie policy or anti-CSRF token can be invoked by a forged form that changes preferences or elevates permissions. If the application embeds sensitive data (e.g., roles or permissions) within MongoDB documents and relies solely on cookie-based authentication without verifying the request origin, an attacker can manipulate those fields. This becomes particularly dangerous when combined with common misconfigurations such as lax CORS policies or missing SameSite and Secure cookie attributes, enabling attackers to forge requests that directly modify MongoDB documents on behalf of the victim.

Another vector involves endpoints that accept raw JSON or form data to update MongoDB documents without ensuring the intent of the caller. For example, an update that modifies isAdmin or linked account IDs should always tie the change to the authenticated user’s identity verified on the server, not just a session cookie. If Axum handlers deserialize user input and apply it directly to a MongoDB update_one filter that uses an ID supplied by the client, a forged request can change other users’ records. The combination of Axum’s flexible routing and MongoDB’s document-oriented model means that any missing origin checks or missing per-request authorization can lead to unauthorized mutations, data leakage, or privilege escalation.

To mitigate CSRF when using Axum with MongoDB, implement layered defenses: strict cookie attributes, anti-CSRF tokens for state-changing operations, and server-side authorization that ties every MongoDB update to the authenticated user’s identity. Below are concrete, realistic code examples for Axum handlers using the official MongoDB Rust driver.

First, configure your session cookie with SameSite and Secure attributes to reduce the likelihood of cross-origin requests sending the session identifier:

use axum::response::Response;
use axum::http::{HeaderMap, HeaderValue, SetCookie};

fn build_secure_cookie(session_id: &str) -> HeaderMap {
    let mut headers = HeaderMap::new();
    let cookie = format!("session={}; Path=/; HttpOnly; Secure; SameSite=Lax", session_id);
    headers.insert(SetCookie::from(cookie).to_string().parse().unwrap(), HeaderValue::from_static(""));
    headers
}

Second, require a custom anti-CSRF header for any write operation and validate it server-side before applying changes to MongoDB. This ensures that requests originating from cross-site forms are rejected even if cookies are present:

use axum::{routing::post, Json, Router};
use mongodb::{Client, Collection};
use serde::{Deserialize, Serialize};
use std::net::SocketAddr;

#[derive(Deserialize)]
struct UpdatePreferences {
    theme: String,
    // other fields...
}

async fn update_preferences(
    Json(payload): Json,
    // extract anti-csrf header
    headers: axum::http::HeaderMap,
    // assuming you have a MongoDB collection for user preferences
    prefs_collection: Collection,
    // extract user identity from validated session (e.g., via middleware)
    user_id: String,
) -> Result, (axum::http::StatusCode, String)> {
    let csrf_token = headers.get("X-CSRF-Token")
        .ok_or((axum::http::StatusCode::FORBIDDEN, "Missing CSRF token".into()))?;
    // validate csrf_token matches the one stored in session or a cryptographically signed token
    // For simplicity, assume validation passes here

    let filter = doc! { "user_id": &user_id };
    let update = doc! { "$set": { "theme": payload.theme } };
    prefs_collection.update_one(filter, update).await
        .map_err(|e| (axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    Ok(Json(()))
}

#[tokio::main]
async fn main() {
    let client = Client::with_uri_str("mongodb://localhost:27017").await.unwrap();
    let db = client.database("myapp");
    let prefs_collection = db.collection("preferences");

    let app = Router::new()
        .route("/api/preferences", post(update_preferences))
        // other routes
        .with_state(Arc::new(prefs_collection));

    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

Third, ensure that every update to MongoDB validates ownership by including the authenticated user’s identifier in the query filter, preventing attackers from modifying other users’ documents even if they can guess IDs:

use mongodb::bson::{doc, Document};

async fn change_user_role(
    user_id: String,
    target_user_id: String,
    new_role: String,
    users_collection: Collection,
) -> Result<(), String> {
    // Only modify the target document if it belongs to the authenticated user
    let filter = doc! {
        "_id": &target_user_id,
        "owner_id": &user_id,
    };
    let update = doc! {
        "$set": { "role": new_role },
    };
    let result = users_collection.update_one(filter, update).await
        .map_err(|e| e.to_string())?;
    if result.matched_count == 0 {
        return Err("Unauthorized or document not found".into());
    }
    Ok(())
}

Finally, combine these measures with server-side origin checks and strict CORS policies in Axum to further reduce CSRF surface. This approach ensures that even if a forged request reaches your endpoints, it cannot safely modify MongoDB state without explicit intent verification and correct ownership checks.