Fix Mass Assignment in Actix Web

Mass assignment in Actix Web occurs when untrusted JSON input is deserialized directly into internal models or database entities. In the Rust ecosystem, this usually happens by reusing a single struct for both API interaction and data persistence. If a struct contains sensitive fields like 'is_admin' or 'role', an attacker can inject these into the request body to escalate privileges or manipulate internal state.

The Vulnerable Pattern

#[derive(Serialize, Deserialize)]
struct UserProfile {
    pub username: String,
    pub bio: String,
    pub is_admin: bool, // Sensitive field
}
// Vulnerable Handler
async fn update_profile(profile: web::Json) -> HttpResponse {
// Attacker sends: {“username”: “hacker”, “is_admin”: true}
// Actix-web deserializes it directly, granting admin rights.
db::save_user(profile.into_inner()).await;
HttpResponse::Ok().finish()
}

The Secure Implementation

To kill mass assignment, implement the Data Transfer Object (DTO) pattern. Create dedicated structs for incoming requests that only expose the fields a user is permitted to change. Use Serde attributes like #[serde(deny_unknown_fields)] to reject payloads containing extra keys. By decoupling your public-facing API schema from your internal database schema, you ensure that the type system itself enforces security boundaries, making it impossible for an attacker to overwrite restricted fields through deserialization.

#[derive(Deserialize)]
struct UpdateProfileRequest {
    pub username: String,
    pub bio: String,
    // is_admin is excluded from the DTO
}
// Secure Handler
async fn update_profile(req: web::Json) -> HttpResponse {
let user_id = 123; // Derived from session/JWT
let data = req.into_inner();
// Explicitly mapping fields prevents injection
db::update_user_fields(user_id, data.username, data.bio).await;

HttpResponse::Ok().finish()
}