Mass Assignment Exploit in Actix (Rust)

Mass assignment (also known as over-posting) occurs when an API endpoint binds incoming request data directly to a data model or struct without whitelisting fields. In Actix with Rust, this typically involves deserializing JSON into a struct that contains more fields than intended for client assignment, such as an admin flag, role identifier, or database primary key. If the endpoint uses the struct directly in an update or creation flow, an attacker can supply unexpected fields to escalate privileges or modify sensitive records.

Consider a user profile update endpoint that binds to a UserUpdate struct. Without explicit field filtering, an attacker can add an is_admin field and gain elevated permissions:

use actix_web::{post, web, HttpResponse};
use serde::Deserialize;

#[derive(Deserialize)]
struct UserUpdate {
    email: Option,
    name: Option,
    is_admin: Option, // unintentionally exposed
}

#[post("/users/{id}")]
async fn update_user(
    path: web::Path,
    body: web::Json<UserUpdate>,
) -> HttpResponse {
    let user_id = path.into_inner();
    let update = body.into_inner();
    // hypothetical ORM call that applies all non-None fields
    // is_admin may be set if present in JSON
    HttpResponse::Ok().finish()
}

The risk is amplified when the struct maps closely to database columns or ORM models. In Rust, the common practice of deriving Deserialize on public structs without field-level control makes it easy to inadvertently expose settable attributes. This maps to the OWASP API Top 10 A1: Broken Object Level Authorization (BOLA) / IDOR, where improper authorization checks allow one user to act on another’s resources.

Real-world impact can be demonstrated with a targeted request that overrides administrative state:

{
  "email": "user@example.com",
  "is_admin": true
}

If the server applies all non-None fields, the attacker becomes an admin. Even when using query parameters or path bindings, mass assignment can occur if deserialization is too permissive. The scanner category of Property Authorization exists precisely to detect such authorization gaps, and findings often reference compliance mappings to frameworks like OWASP API Top 10 and SOC2 controls.

middleBrick’s scans include checks aligned with BOLA/IDOR and Property Authorization, highlighting endpoints where deserialization exposes sensitive fields. These findings come with severity ratings and remediation guidance to help developers tighten data binding. In production, combining strict schema validation with server-side field filtering is essential to prevent unauthorized state changes.

To prevent mass assignment in Actix, explicitly control which fields are deserializable and do not rely on automatic mapping of all JSON keys. Two effective patterns are: (1) using a dedicated input struct with only permitted fields, and (2) manually parsing and applying changes rather than blindly merging all deserialized values.

Pattern 1: Whitelist input struct

Define a struct that includes only the fields a client should be allowed to set. Keep sensitive fields like is_admin out of this struct or make them private and manage them through service logic:

use actix_web::{post, web, HttpResponse};
use serde::Deserialize;

#[derive(Deserialize)]
struct UserProfileInput {
    email: Option,
    name: Option,
}

#[derive(Deserialize)]
struct UserProfileFull {
    email: String,
    name: String,
    is_admin: bool,
}

#[post("/users/{id}")]
async fn update_user_safe(
    path: web::Path,
    body: web::Json<UserProfileInput>,
    // Assume get_user and save_user are service functions that enforce authorization
)
{
    let user_id = path.into_inner();
    let input = body.into_inner();
    // Only fields from UserProfileInput can come from the client
    let mut full = get_user(user_id);
    if let Some(email) = input.email {
        full.email = email;
    }
    if let Some(name) = input.name {
        full.name = name;
    }
    // is_admin is never set from request body
    save_user(full);
    HttpResponse::Ok().finish()
}

This ensures that only email and name can be modified by the client. The server retains control over is_admin and any other sensitive attributes.

Pattern 2: Manual application with validation

For more complex updates, deserialize into a serde_json::Value or a map and selectively apply known fields, rejecting any unrecognized keys:

use actix_web::{post, web, HttpResponse};
use serde_json::Value;

#[post("/users/{id}/strict")]
async fn update_user_strict(
    path: web::Path,
    body: web::Json<Value>,
) -> HttpResponse {
    let obj = body.as_object().expect("JSON object required");
    // Reject unexpected keys
    let allowed = ["email", "name"];
    for key in obj.keys() {
        if !allowed.contains(&key.as_str()) {
            return HttpResponse::BadRequest().body(format!("Unexpected field: {}", key));
        }
    }
    // Apply only known fields
    let email = obj.get("email").and_then(|v| v.as_str()).map(String::from);
    let name = obj.get("name").and_then(|v| v.as_str()).map(String::from);
    // ... apply updates via service layer
    HttpResponse::Ok().finish()
}

This approach gives full control over which fields are accepted and how they are transformed, avoiding reliance on automatic struct mapping. It also aligns with the Principle of Least Privilege, a foundational element of secure authorization.

When using the CLI tool, you can verify your endpoints with middlebrick scan <url> to see if mass assignment risks are flagged. Teams on the Pro plan can enable continuous monitoring to catch regressions early, and the GitHub Action can fail builds when new risky endpoints are introduced. The MCP Server allows you to scan APIs directly from your Rust development environment, integrating security checks into your workflow without disrupting existing tooling.