Mass Assignment in Actix with Cockroachdb

Mass Assignment occurs when an API binds user-supplied JSON directly to a database model or struct without filtering fields. In Actix, this typically happens when a handler deserializes a request body into a Diesel or SQLx model and then passes that model to Cockroachdb. Because Cockroachdb is compatible with PostgreSQL wire protocol, the patterns used with Postgres apply: if your Actix code uses a struct with many fields and only intends a subset to be user-writable, an attacker can supply extra fields to set unauthorized properties.

With Cockroachdb, the risk is amplified when the Actix service builds SQL dynamically or uses ORM-style updates without an allowlist. For example, consider a handler that updates a user profile by binding the entire request to a struct that includes is_admin, balance, or permissions. If the handler calls something like diesel::update(users.filter(id.eq(user_id))).set(&user_data).execute() with user_data derived from the full body, an attacker can change any mapped column. Cockroachdb’s strict SQL semantics mean that any column present in the model and not explicitly excluded will be updated to the attacker’s value, leading to privilege escalation or data manipulation.

Another common pattern is using query builders in Actix with Cockroachdb where developers construct INSERT or UPDATE statements from structs that contain sensitive fields but do not explicitly whitelist inputs. Even with strongly typed queries, if the struct maps 1:1 to the table columns and the application does not strip non-whitelisted keys before binding, mass assignment becomes possible. This maps directly to the OWASP API Top 10 A01:2023 — Broken Object Level Authorization, where attackers change object IDs or authorization flags by supplying unexpected parameters.

In a black-box scan, middleBrick tests exactly this scenario: it submits payloads with unexpected fields such as role, confirmed_at, or is_superuser and checks whether the backend accepts them into Cockroachdb. If your Actix endpoints deserialize into broad structs and pass them to Cockroachdb without filtering, middleBrick will flag findings under BOLA/IDOR and BFLA/Privilege Escalation with clear remediation guidance to use explicit allowlists.

To prevent mass assignment in Actix when working with Cockroachdb, always separate the database model from the input model and explicitly select which fields are mutable. Use a dedicated DTO (Data Transfer Object) for requests and map only allowed fields to your domain model before issuing SQL to Cockroachdb. Below are concrete code examples using SQLx with Cockroachdb in Actix.

Example 1: Whitelisted update with SQLx and Actix

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

#[derive(Deserialize)]
pub struct UpdateUserPayload {
    pub display_name: Option,
    pub email: Option,
    // Do not include is_admin, role, or balance here
}

#[derive(Serialize)]
pub struct UserResponse {
    pub id: i32,
    pub display_name: String,
    pub email: String,
}

pub async fn update_user(
    path: web::Path,
    payload: web::Json,
    pool: web::Data,
) -> HttpResponse {
    let user_id = path.into_inner();
    let payload = payload.into_inner();

    // Build dynamic update only for permitted fields
    let mut query = "UPDATE users SET".to_string();
    let mut params: Vec<&(dyn sqlx::types::Type + Sync)> = Vec::new();
    let mut set_count = 0;

    if let Some(display_name) = &payload.display_name {
        set_count += 1;
        query += &format!(" display_name = ${}", set_count);
        params.push(display_name);
    }
    if let Some(email) = &payload.email {
        set_count += 1;
        query += &if set_count > 1 { "," } else { "" };
        query += &format!(" email = ${}", set_count);
        params.push(email);
    }
    if set_count == 0 {
        return HttpResponse::BadRequest().body("No fields to update");
    }
    query += &format!(" WHERE id = ${}", set_count + 1);
    params.push(&user_id);

    sqlx::query(&query)
        .bind_all(¶ms)
        .execute(&*pool)
        .await
        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;

    let updated = sqlx::query_as::<_, UserResponse>("SELECT id, display_name, email FROM users WHERE id = $1")
        .bind(user_id)
        .fetch_one(&*pool)
        .await
        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;

    HttpResponse::Ok().json(updated)
}

Example 2: Insert with explicit column names in Cockroachdb via Actix and SQLx

use actix_web::web;
use serde::Deserialize;

#[derive(Deserialize)]
pub struct CreateUserPayload {
    pub email: String,
    pub display_name: String,
    // Do not include created_at, verified, or is_admin
}

pub async fn create_user(
    pool: web::Data,
    payload: web::Json,
) -> Result {
    let payload = payload.into_inner();

    // Explicit column list ensures only intended fields are set
    sqlx::query("
        INSERT INTO users (email, display_name, created_at)
        VALUES ($1, $2, now())
        RETURNING id, email, display_name, created_at
    ")
    .bind(&payload.email)
    .bind(&payload.display_name)
    .fetch_one(&*pool)
    .await
    .map(|row| HttpResponse::Ok().json(row))
    .map_err(|e| actix_web::error::ErrorInternalServerError(e))
}

These examples enforce strict field mapping, ensuring that even if Cockroachdb receives a SQL-compatible request, only whitelisted columns are affected. In production, combine this with middleware that validates ownership and scopes to prevent IDOR, which middleBrick identifies separately under BOLA/IDOR checks.