Mass Assignment in Axum with Cockroachdb

Mass assignment occurs when an API deserializes HTTP request data directly into a data model without filtering which fields are applied. In Axum, this typically involves binding request payloads to structs that are then used to construct SQL statements for Cockroachdb. Because Cockroachdb is compatible with PostgreSQL wire protocol, developers often use crates like sqlx with postgres feature, and mass assignment risk arises when struct fields are mapped 1:1 to database columns without explicit field selection.

Consider a user profile update endpoint. If the Axum handler accepts a JSON payload and deserializes it into a UserUpdate struct that mirrors the database table columns, an attacker can supply extra fields such as is_admin or balance. When the handler passes this struct to a query like UPDATE users SET $1 WHERE id = $2 using a naive mapping, unintended columns may be modified. This is a BFLA/Privilege Escalation and BOLA/IDOR concern because the attacker can modify attributes they should not control.

The risk is compounded when the struct is reused across different permission contexts. For example, an authentication struct used in registration might include a confirmed_at timestamp. If the same struct is used in an admin update path without field filtering, an authenticated or unauthenticated attacker might set confirmed_at to a past timestamp to bypass email confirmation, or set sensitive fields that Cockroachdb will persist because the SQL layer does not restrict column assignment at the application level.

In Axum, handlers often rely on extractors such as Json<T> or Form<T>. Without manual field filtering or the use of #[serde(default)] and selective deserialization, any extra keys in the JSON are silently mapped to struct fields. Because Cockroachdb does not enforce application-level field permissions, the database will execute the statement with the attacker-supplied values, leading to data exposure or privilege escalation as seen in the OWASP API Top 10 A1: Broken Object Level Authorization.

Real-world patterns include using a single struct for both insert and update operations, or deriving SQL column lists from struct field names via reflection-like macros. These patterns map fields by position or name and do not strip unexpected keys, which enables injection of malicious values. The scanner’s checks for BOLA/IDOR and BFLA/Privilege Escalation are designed to detect such mappings by correlating endpoint definitions with data exposure and authorization checks across the 12 security checks.

Remediation focuses on explicit field selection, strict deserialization, and avoiding direct struct-to-column mapping. In Axum, prefer using separate request structs that include only the fields allowed for the caller’s scope, and map them to domain models before constructing SQL.

Example of a vulnerable handler using mass assignment:

// UNSAFE: direct mapping of all JSON fields to database columns
async fn update_profile(
    Extension(pool): Extension>,
    Json(payload): Json<serde_json::Value>
) -> Result<impl IntoResponse, (StatusCode, String)> {
    let user_id = payload["id"].as_i64().unwrap();
    let query = format!("UPDATE users SET properties = $1 WHERE id = $2");
    sqlx::query(&query)
        .bind(payload.to_string())
        .bind(user_id)
        .execute(&pool)
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    Ok(StatusCode::OK)
}

Instead, define a scoped request struct and select columns explicitly:

use serde::Deserialize;

#[derive(Deserialize)]
struct UpdateProfileRequest {
    display_name: Option<String>,
    email: Option<String>,
    // Intentionally excluding is_admin, balance, confirmed_at
}

async fn update_profile(
    Extension(pool): Extension<Arc<Pool>>,
    Json(payload): Json<UpdateProfileRequest>,
    Path(user_id): Path<i64>
) -> Result<impl IntoResponse, (StatusCode, String)> {
    let mut query = String::from("UPDATE users SET ");
    let mut params: Vec<(&str, &dyn sqlx::Encode<_, _>)> = Vec::new();
    let mut sep = "";
    if let Some(display_name) = &payload.display_name {
        query.push_str(&format!("{}display_name = ${}", sep, params.len() + 1));
        params.push(("display_name", display_name as &dyn sqlx::Encode<_, _>));
        sep = ", ";
    }
    if let Some(email) = &payload.email {
        query.push_str(&format!("{}email = ${}", sep, params.len() + 1));
        params.push(("email", email as &dyn sqlx::Encode<_, _>));
        sep = ", ";
    }
    query.push_str(" WHERE id = $");
    query.push_str(&((params.len() + 1).to_string()));
    params.push(("id", &user_id as &dyn sqlx::Encode<_, _>));

    sqlx::query(&query)
        .bind_all(params.iter().map(|(_, v)| *v))
        .execute(&pool)
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    Ok(StatusCode::OK)
}

For inserts, avoid selecting all columns from the struct. Use explicit column lists in SQL and bind only allowed fields:

#[derive(Deserialize)]
struct CreateUserRequest {
    email: String,
    display_name: String,
    // Do not include password_hash here; derive a separate auth struct
}

async fn create_user(
    Extension(pool): Extension<Arc<Pool>>,
    Json(payload): Json<CreateUserRequest>
) -> Result<impl IntoResponse, (StatusCode, String)> {
    sqlx::query("INSERT INTO users (email, display_name, created_at) VALUES ($1, $2, $3)")
        .bind(&payload.email)
        .bind(&payload.display_name)
        .bind(chrono::Utc::now())
        .execute(&pool)
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    Ok(StatusCode::CREATED)
}

When using ORM-like patterns with sqlx macros, ensure that the generated queries reference specific columns rather than relying on automatic struct mapping. Cockroachdb’s PostgreSQL compatibility means that standard sqlx

Additionally, enable schema-level protections where possible: use Cockroachdb’s ALTER TABLE to restrict column ownership or use row-level security policies to ensure that even if a field is supplied, the database will reject unauthorized updates. Combine these with Axum guards that validate ownership before constructing queries.