Fix Mass Assignment in Poem

Mass Assignment in the Poem framework (Rust) occurs when untrusted JSON payloads are deserialized directly into internal models or database entities. Attackers exploit this by 'overposting'—including extra fields like 'role', 'is_admin', or 'balance' that the application didn't intend to expose for modification. In Rust, this is a logic flaw facilitated by Serde's permissive deserialization into shared structs.

The Vulnerable Pattern

#[derive(serde::Deserialize, sqlx::FromRow)]
struct User {
    id: i32,
    username: String,
    is_admin: bool, // Sensitive field
}
#[handler]
async fn update_user(Json(user_update): Json) -> impl IntoResponse {
// VULNERABLE: The attacker can send {“username”: “hacker”, “is_admin”: true}
// and the deserializer will populate the is_admin field.
db::update_user(user_update).await;
StatusCode::OK
}

The Secure Implementation

The fix implements the Data Transfer Object (DTO) pattern. By creating a dedicated 'UserUpdateRequest' struct, you define a strict whitelist of mutable fields. Even if an attacker sends an 'is_admin' field in the JSON body, the Serde deserializer will ignore it because it is not defined in the DTO. This decouples your external API contract from your internal data schema, ensuring that sensitive state transitions remain under the control of your business logic, not the request payload.

#[derive(serde::Deserialize)]
struct UserUpdateRequest {
    // ONLY include fields the user is allowed to change
    username: Option,
    bio: Option,
}
#[handler]
async fn update_user(Json(payload): Json) -> impl IntoResponse {
let mut user = db::get_current_user().await;
// Explicitly map allowed fields to the internal model
if let Some(new_name) = payload.username {
    user.username = new_name;
}

db::save_user(user).await;
StatusCode::OK
}