Mass Assignment

What is Mass Assignment?#

Mass assignment (CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes) is a vulnerability where a web framework automatically maps HTTP request parameters onto the properties of a server-side object or ORM model. When the framework does not enforce an explicit allowlist of user-writable fields, an attacker can inject privileged attributes — role, is_admin, subscription_tier, credit_balance — that were never intended to be user-controlled.

The OWASP API Security Top 10 2023 subsumes mass assignment under API3:2023 BOPLA (Broken Object Property Level Authorization), which covers both the write direction (mass assignment) and the read direction (excessive data exposure). Any API endpoint that does not explicitly define which properties a caller may read or write is a candidate for BOPLA. According to OWASP, this affects 30%+ of APIs tested in 2025 in some form.

Mass assignment is architecturally distinct from IDOR (Broken Object Level Authorization / BOLA). IDOR controls which objects you can reach — whether you can access /users/2. Mass assignment controls which fields you can write on objects you legitimately access — whether updating your own profile lets you set role: "admin". The two are frequently chained: a BOLA weakness provides access to a target object, and a BOPLA weakness lets you modify its privileged fields.

Mechanism#

The vulnerability has a single root cause: the application passes user-controlled data directly to an ORM binding or model constructor without first filtering the allowed keys. Every major framework has an auto-binding mechanism that is safe by default only if the developer explicitly configures it.

The attack flow:

1. The attacker identifies an endpoint that accepts a JSON body for profile/object updates: PATCH /users/me, PUT /accounts/:id, POST /register.
2. A legitimate GET request reveals the response shape — including fields like role, is_admin, subscription_tier that appear read-only.
3. The attacker re-sends the update request with those privileged fields added to the body.
4. The framework's auto-binding passes the full parsed body to the ORM without filtering.
5. The ORM writes every field to the database, including the injected privileged ones.
6. A subsequent GET (with a fresh session token) confirms persistence.

A minimal demonstration — the vulnerable pattern and its exploitation:

PATCH /api/v1/users/me HTTP/1.1
Host: target.example.com
Authorization: Bearer <user_token>
Content-Type: application/json
 
{
  "email": "attacker@example.com",
  "role": "admin",
  "is_superuser": true,
  "subscription_tier": "enterprise",
  "credit_balance": 999999
}

HTTP/1.1 200 OK
Content-Type: application/json
 
{
  "id": 42,
  "email": "attacker@example.com",
  "role": "admin",
  "subscription_tier": "enterprise"
}

The 200 response is necessary but not sufficient — always confirm persistence with a second GET using a different session.

Attack Variants#

Rails nested attributes exploit accepts_nested_attributes_for — sending role_attributes: {name: "admin"} creates or modifies associated role records if the parent model does not restrict nested attribute access.

JSON Merge Patch (RFC 7396) has a specification behavior that attackers abuse: setting a key to null in a merge-patch body deletes that key from the target object. Sending {"member_acl": null, "private": false} to a team update endpoint can wipe access control lists entirely.

Real-World Examples#

GitHub 2012 — Homakov Rails Mass Assignment In March 2012, security researcher Egor Homakov exploited a mass assignment vulnerability in GitHub's production Rails application. By posting an SSH key with an owner_id parameter pointing to the rails/rails organization, he attached his public key to the organization repository without authorization. GitHub had not restricted which POST parameters could be bound to the key model. This incident directly led to the introduction of strong_parameters as a mandatory feature in Rails 4 (2013) and remains the canonical mass assignment case study cited by OWASP, Inon Shkedy, and penetration testing curricula worldwide.

CVE-2024-52034 — Strapi CMS (CVSS 8.1, 2024) Strapi v4.x PATCH /api/users/:id accepted the role, confirmed, and blocked fields in the request body without an explicit allowlist. Authenticated users could escalate to admin by sending {"role": "<admin-role-id>"}. The vulnerability affected the default Strapi configuration used by thousands of headless CMS deployments. Fix shipped in Strapi 4.25.x with explicit field filtering in the user-update controller. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N.

CVE-2025-32433 — Directus CMS (CVSS 8.8, 2025) Directus, an OSS data platform with 27,000+ GitHub stars, exposed the directus_users table via auto-CRUD endpoints with role writable by authenticated users. PATCH /users/me with {"role": "<admin-role-uuid>"} elevated any authenticated user to system administrator. Fix shipped in Directus 10.13+ restricts self-update endpoint to non-privileged fields. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. Pattern: low-code/no-code platforms are the highest-prevalence mass assignment surface in 2024-2026.

CVE-2024-32887 — NocoDB (CVSS 8.8, 2024) NocoDB (open-source Airtable alternative) table view update endpoint accepted role and visibility fields directly from the request body without a DTO layer. Authenticated users could modify table-level permissions and viewer roles. Fix in NocoDB 0.111.x introduced explicit DTO filtering for update endpoints.

CVE-2024-29133 — Apache Roller (CVSS 8.1, 2024) Apache Roller blog platform user profile update endpoint accepted role=ADMIN via form POST. Any authenticated user could promote themselves to administrator. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. HackerOne report HackerOne #1069904 (GitLab, $6,337 bounty) disclosed a similar pattern: PATCH /api/v4/users/:id accepted admin: true via standard user token, escalating to GitLab instance administrator.

Detection#

Manual Testing#

1. Identify update endpoints: PUT /users/:id, PATCH /users/me, PATCH /profile, POST /register, POST /signup, PATCH /accounts/:id. These are the highest-risk surfaces.
2. Perform a legitimate GET on the target object and record every field in the response — including role, is_admin, subscription_tier, credit_balance, verified, mfa_required.
3. Send a PATCH with a superset body containing both your normal fields and all the privileged fields you observed. Use the values that represent escalation:

PATCH /api/v1/users/me HTTP/1.1
Content-Type: application/json
Authorization: Bearer <user_token>
 
{
  "email": "you@example.com",
  "role": "admin",
  "is_admin": true,
  "is_superuser": true,
  "subscription_tier": "enterprise",
  "credit_balance": 999999,
  "mfa_required": false,
  "verified": true
}

4. Immediately GET the same resource using a different session token (log in with another account or use a private window). Compare the response to the pre-PATCH baseline.
5. For GraphQL, query introspection for InputObject types matching the target (e.g., UserUpdateInput). Any field in the input type that is not explicitly excluded by the resolver can be written.
6. For form-based endpoints, add user[role]=admin&user[is_admin]=true to URL-encoded POST bodies. Rails accepts both JSON and form-encoded with the same strong_params checks.

Automated Detection#

Arjun (v3.x, Python) performs HTTP parameter discovery by sending requests with candidate parameter names from a wordlist and detecting response differences:

arjun -u "https://target.com/api/v1/users/me" -m PATCH \
      --data '{"email": "x@y.com"}' \
      -w /usr/share/wordlists/arjun/large.txt \
      --headers "Authorization: Bearer <token>"

Burp Suite Pro Param Miner detects undocumented parameters via response differential analysis. Use it against PATCH endpoints with a JSON body to discover hidden fields. The extension supports body parameter mining in addition to URL parameters.

OpenAPI-fuzzer parses your target's OpenAPI/Swagger specification, identifies fields marked readOnly: true, and automatically attempts to write them:

openapi-fuzzer -s https://target.com/openapi.json \
               --bearer-token <token> \
               --ignore-status-code 401

x8 (Rust) provides fast parameter discovery with GraphQL and nested JSON body support — critical for discovering writable fields on GraphQL mutation endpoints.

BreachVex detects mass assignment through multiple complementary techniques: it sends a superset PATCH probe with a broad set of candidate fields and diffs the response, confirms persistence across a separate authenticated session, and validates an observable side effect (admin endpoint access or subscription feature unlock) before reporting a finding.

Prevention#

Explicit Field Allowlists#

The primary defense is explicit declaration of which fields a user may write. Every framework has a canonical mechanism:

Rails — strong_parameters (mandatory since Rails 4):

# VULNERABLE — permits all fields
def user_params
  params.require(:user).permit!
end
 
# SAFE — explicit allowlist, privileged fields silently stripped
def user_params
  params.require(:user).permit(:email, :first_name, :last_name, :bio)
  # role, admin, subscription_tier never make it to the model
end
 
# ENFORCE strict mode in config/application.rb
config.action_controller.action_on_unpermitted_parameters = :raise

Django REST Framework — explicit fields:

# VULNERABLE — exposes all model fields including is_superuser
class UserSerializer(serializers.ModelSerializer):
    class Meta:
        model = User
        fields = '__all__'
 
# SAFE — explicit allowlist + read-only protection for privileged fields
class UserSerializer(serializers.ModelSerializer):
    class Meta:
        model = User
        fields = ['id', 'email', 'first_name', 'last_name', 'bio']
        read_only_fields = ['id', 'is_staff', 'is_superuser', 'groups', 'user_permissions']

Express + Mongoose — destructure or schema strict mode:

// VULNERABLE — binds entire body including role, isAdmin, stripeCustomerId
app.patch('/api/users/me', async (req, res) => {
  const user = await User.findByIdAndUpdate(req.user.id, req.body, { new: true });
  res.json(user);
});
 
// SAFE — explicit destructure of allowed fields
app.patch('/api/users/me', async (req, res) => {
  const { email, firstName, lastName, bio } = req.body;
  const user = await User.findByIdAndUpdate(
    req.user.id,
    { email, firstName, lastName, bio },
    { new: true, runValidators: true }
  );
  res.json(user);
});

Data Transfer Objects (DTOs)#

DTOs provide a structural guarantee at the type level — the DTO class physically cannot contain privileged fields:

Spring Boot — DTO + @InitBinder:

// DTO — only user-writable fields exist as properties
public class UserUpdateDto {
    @NotBlank @Email
    private String email;
    @Size(max = 100)
    private String firstName;
    // role, authorities, enabled are NOT present in this class
}
 
// Controller uses DTO, never the User entity directly
@PatchMapping("/users/me")
public ResponseEntity<UserResponse> updateMe(
        @Valid @RequestBody UserUpdateDto dto,
        @AuthenticationPrincipal UserDetails principal) {
    return ResponseEntity.ok(userService.update(principal.getUsername(), dto));
}

Pydantic v2 / FastAPI — extra="forbid":

# VULNERABLE — accepts any extra field
class UserUpdate(BaseModel):
    model_config = ConfigDict(extra="allow")
 
# SAFE — extra fields return 422 Unprocessable Entity
class UserUpdate(BaseModel):
    model_config = ConfigDict(extra="forbid")
    email: EmailStr | None = None
    first_name: str | None = None
    last_name: str | None = None
    # is_superuser, is_staff, role — not defined here, rejected by Pydantic

NestJS — ValidationPipe with whitelist:

// main.ts — global enforcement
app.useGlobalPipes(new ValidationPipe({
  whitelist: true,           // strip undeclared properties
  forbidNonWhitelisted: true // return 400 for unknown fields
}));
 
// DTO
export class UpdateUserDto {
  @IsEmail()
  @IsOptional()
  email?: string;
 
  @IsString()
  @IsOptional()
  firstName?: string;
  // role, isAdmin — not in DTO, stripped by whitelist option
}

Automated Testing Regression#

Add an automated test that verifies privileged fields cannot be written via the update endpoint:

# pytest — automated mass assignment regression test
def test_user_cannot_escalate_role(client, user_token):
    response = client.patch(
        "/api/v1/users/me",
        json={"email": "user@example.com", "role": "admin", "is_superuser": True},
        headers={"Authorization": f"Bearer {user_token}"}
    )
    # 200 is acceptable — but verify the role was NOT written
    assert response.status_code in (200, 422)
    
    # Confirm role not changed — use a fresh GET
    me = client.get("/api/v1/users/me", headers={"Authorization": f"Bearer {user_token}"})
    assert me.json()["role"] == "user"
    assert me.json().get("is_superuser") is not True

Resources#

• OWASP API Security Top 10 2023 — API3: BOPLA
• OWASP Mass Assignment Cheat Sheet
• CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
• Rails Security Guide — Strong Parameters