Mass Assignment Exploit in Axum (Rust)

Mass assignment (also known as over-posting or property assignment) occurs when an API binds user-supplied JSON directly to a server-side data model without filtering which fields are allowed. In Axum with Rust, this typically happens when a handler deserializes request bodies into a struct that contains more fields than intended for client input, such as an admin flag, internal ID, or version stamp. Because Rust’s strong typing does not inherently prevent assigning unexpected fields during deserialization, developers must explicitly guard which fields are mutable or exposed.

When an OpenAPI specification for an endpoint defines a request schema that includes privileged fields but the runtime handler uses a generic struct or relies on automatic mapping, the unauthenticated attack surface includes mass assignment. For example, an endpoint accepting a UserUpdate payload may inadvertently allow a client to supply is_admin or permissions fields. If the handler passes the deserialized struct directly to a service or ORM that performs an update, those extra fields can modify database records in unintended ways.

Axum does not provide built-in field-level filtering; it relies on the developer to choose the right extraction and deserialization patterns. Using a generic serde deserialization approach without a dedicated DTO (data transfer object) or without explicitly ignoring unknown or sensitive fields increases the likelihood of mass assignment. The scanner’s BFLA/Privilege Escalation and Property Authorization checks can detect whether request properties are properly authorized and whether the API surface exposes fields that should be immutable. The Input Validation check also examines whether the API correctly constrains which fields are accepted and how they are interpreted during deserialization.

In practice, an attacker can probe such endpoints by sending crafted JSON that includes sensitive fields. If the server applies the payload naively, the scanner may observe unauthorized state changes during testing, which would be flagged with severity and mapped to frameworks such as OWASP API Top 10 A01: Broken Object Level Authorization. The presence of an OpenAPI spec with $ref resolution helps the scanner cross-reference request definitions with runtime behavior to highlight mismatches between declared and enforced schemas.

To prevent mass assignment in Axum, define separate request DTOs that include only the fields a client should be allowed to set, and map those DTOs to domain models on the server side. Avoid binding user input directly to database or ORM models. Use serde attributes to ignore unknown fields and explicitly opt into the ones you expect.

Example 1: Safe DTO-based handler with selective deserialization.

use axum::extract::Json;
use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize)]
pub struct UserUpdateDto {
    pub email: Option,
    pub name: Option,
    // Intentionally omit is_admin, permissions, internal_id, etc.
}

#[derive(Debug, Serialize)]
pub struct UserResponse {
    pub id: i64,
    pub email: String,
    pub name: String,
    pub is_admin: bool,
}

// In your route handler:
async fn update_user(
    Json(payload): Json,
) -> Result, (axum::http::StatusCode, String)> {
    // Map payload to domain model, applying business logic and defaults
    let updated_user = patch_user_in_db(payload).map_err(|e| {
        (axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string())
    })?;
    Ok(Json(UserResponse {
        id: updated_user.id,
        email: updated_user.email,
        name: updated_user.name,
        is_admin: updated_user.is_admin,
    }))
}

Example 2: Using serde(default) and ignoring unknown fields to increase safety.

use serde::Deserialize;

#[derive(Debug, Deserialize)]
pub struct SafeUpdate {
    #[serde(default)]
    pub name: String,
    #[serde(default)]
    pub email: String,
    #[serde(flatten)]
    pub extra: std::collections::HashMap,
}

Example 3: Rejecting fields not defined in the DTO by configuring serde_json or axum extractors to error on unknown fields, ensuring strict validation.

use serde::Deserialize;

#[derive(Debug, Deserialize)]
#[serde(deny_unknown_fields)]
pub struct StrictUserUpdate {
    pub email: String,
}

Additional practices include using the CLI tool (middlebrick scan <url>) to verify that your endpoints do not allow unintended property updates, integrating the GitHub Action to fail builds when new sensitive fields appear in request schemas, and using the Web Dashboard to track changes over time. The MCP Server can also be used to scan APIs directly from your IDE during development, helping catch mass assignment risks early.