Mass Assignment in Axum with Api Keys

Mass assignment occurs when an API binds incoming request data directly to data models without filtering which fields can be set. In Axum, this typically happens when a handler deserializes JSON into a struct using serde and then uses that struct to create or update a database record. If the struct contains fields such as is_admin, role, or permissions that should be set only server-side, an authenticated user with a valid API key can manipulate these fields simply by including them in the request body.

Using API keys in Axum often involves validating a key from headers (e.g., Authorization: ApiKey <key>) and attaching user claims to the request extension or state. After validation, handlers may decode the JSON payload into a model struct. The vulnerability arises when the same struct is used both for authentication/authorization context and for binding user-controlled input. For example, an attacker with a valid API key can send {"is_admin": true} and, if the server applies mass assignment, the field will be updated, effectively escalating privileges.

Consider an endpoint defined as POST /organizations/{id}/members. If the handler uses a single struct like:

#[derive(serde::Deserialize)]
struct NewMember {
    user_id: Uuid,
    role: String,
    is_admin: bool,
}

and directly inserts NewMember fields into the database, the API allows clients to set is_admin and role. This is a BOLA-like issue when the API key identifies a user who can only modify their own memberships but can elevate others’ roles. The API key proves identity but does not enforce field-level authorization, so mass assignment becomes a privilege escalation path.

In the context of the 12 security checks run by middleBrick, this pattern maps to BOLA/IDOR and BFLA/Privilege Escalation. middleBrick’s OpenAPI/Swagger analysis can detect when request bodies include sensitive fields and flag that runtime behavior allows unauthenticated or insufficiently scoped submissions. The scan does not fix the code but provides prioritized findings with remediation guidance, helping developers understand how API keys in Axum must be paired with explicit field filtering to avoid insecure deserialization.

To prevent mass assignment when using API keys in Axum, separate authentication from data binding. Do not reuse the same struct for both authentication context and user-controlled input. Instead, validate the API key, extract claims, and then bind only the fields that the user is allowed to set.

1. Define distinct structs for input and for database/model layers.

2. Validate the API key and attach user identity to request extensions or a dedicated auth extractor.

3. In the handler, map only permitted fields from the input struct to the model, ignoring sensitive fields.

Example secure implementation:

use axum::{{
    extract::{Extension, Json},
    routing::post,
    Router,
}};
use serde::Deserialize;
use uuid::Uuid;

// Step 1: Input DTO — only fields the client may provide.
#[derive(serde::Deserialize)]
struct CreateMemberInput {
    user_id: Uuid,
    // Do not include role or is_admin here.
}

// Step 2: Model used for database operations.
struct MemberRecord {
    user_id: Uuid,
    role: String,
    is_admin: bool,
}

async fn create_member(
    Extension(auth): Extension<AuthClaims>, // API-key-derived claims.
    Json(payload): Json<CreateMemberInput>,
) -> Result<(), (StatusCode, String)> {
    // Step 3: Map with safe defaults or explicit server-side values.
    let record = MemberRecord {
        user_id: payload.user_id,
        role: "member".to_string(),
        is_admin: false,
    };
    // Persist record using your data access layer.
    Ok(())
}

// Auth extractor example (simplified).
struct AuthClaims {
    subject_id: Uuid,
    // other claims derived from API key validation.
}

#[tokio::main]
async fn main() {
    let app = Router::new()
        .route("/members", post(create_member))
        .layer(Extension(AuthClaims { subject_id: Uuid::new_v4() })); // In practice, derive from API key.
}

This pattern ensures that even with a valid API key, clients cannot set role or is_admin. The API key identifies and authorizes the request, but the handler explicitly assigns safe defaults for sensitive fields.

For teams using the middleBrick ecosystem, the Pro plan’s continuous monitoring and GitHub Action integration can help detect regressions: if a later change adds sensitive fields to the input DTO, the CI gate can fail the build before deployment. The CLI tool (middlebrick scan <url>) can be run locally during development to validate that endpoints do not accept mass-assignable fields.