Mass assignment: how it works, how to test it and how to fix it

Mass assignment is a flaw where an application copies the fields of a request straight into an object, so the caller can set properties the application never meant to expose. One extra field such as role or is_admin in a JSON body can change a protected property. CWE-915 names it "Improperly Controlled Modification of Dynamically-Determined Object Attributes" and lists "Mass Assignment" and "AutoBinding" as other names.

Frameworks call it different things. OWASP's cheat sheet lists mass assignment for Ruby on Rails and Node.js, autobinding for Spring MVC and ASP.NET MVC, and object injection for PHP. OWASP's API list merged it into API3:2023, Broken Object Property Level Authorization.

How does mass assignment work?#

Many frameworks bind request data to a model with one call. If the model has more properties than the form or client uses, a caller who knows or guesses a property name can set it. The server has no rule that says this caller may not write that field.

PATCH /api/v1/users/me HTTP/1.1
Host: api.harbor-notes.example.com
Authorization: Bearer <token-of-test-user-A>
Content-Type: application/json

{ "display_name": "Ana" }

{ "id": 1042, "display_name": "Ana", "role": "member", "plan": "free", "tenant_id": 17 }

The flaw needs two facts: the server binds fields it was not told to accept, and no check blocks the write. The first is a design choice in the code. The second is missing authorization at the property level.

Where does mass assignment hide in APIs?#

It hides wherever the server turns client data into a stored object. Testers look at each of these places:

• PATCH and PUT bodies for profile, settings and account updates.
• POST bodies that create a record, such as sign-up, invitations and orders.
• Nested objects, such as {"profile": {"role": "admin"}}, where the top level is filtered but the child is not.
• GraphQL mutation inputs, where the input type may list more fields than the UI uses.
• Mobile app and single-page app calls, where the client hides a field the API still accepts.
• Bulk and import endpoints that take whole objects.

Sensitive fields testers try, always on test accounts and records:

Candidates come from the API's own output. Response bodies list the properties of each object. OpenAPI specs and GraphQL introspection (if enabled) list more. Client-side JavaScript bundles often contain model fields. Error messages sometimes name a rejected field, which confirms that it exists.

What are the real cases?#

The best-known case is GitHub in 2012. OWASP's cheat sheet states that "In 2012, GitHub was hacked using mass assignment." A user could attach a public key to any organization, which allowed changes to that organization's repositories. The cheat sheet does not give a day or a CVE for it.

A second case is in the framework itself. CVE-2013-0269 was published on 13 February 2013. NVD says the JSON gem for Ruby before 1.5.5, 1.6.x before 1.6.8 and 1.7.x before 1.7.7 allowed remote attackers to cause a denial of service or "bypass the mass assignment protection mechanism" through a crafted JSON document. The weakness is listed as CWE-20. It shows that a protection layer can have its own flaws, so the allow-list belongs in your code too.

Mass assignment, IDOR, BOPLA and parameter pollution: what differs?#

These four are close, and one request can touch more than one.

How do you prevent mass assignment?#

Decide per operation which fields a caller may write, and bind only those. OWASP's cheat sheet gives the architectural answer: use Data Transfer Objects (DTOs) so that only fields meant to be editable are in the object you bind. When you must bind to a model, allow-list the permitted fields. Do not rely on a block-list alone. A DTO and an allow-list limit what can be written, and they do not replace an authorization check on the object and the operation.

Set sensitive values on the server: owner, tenant, role and plan come from the session or from business logic, never from the body. Reject unknown fields where the framework allows, because a clear 400 helps your tests find gaps.

Fixes by framework#

Each pair shows the risky form and the fixed form.

Ruby on Rails uses strong parameters:

# Risky: binds every submitted attribute
User.update(params[:user])
# Fixed: names the writable attributes
User.update(params.require(:user).permit(:display_name, :avatar_url))

Django REST Framework lists serializer fields and marks others read-only:

# Risky: all model fields are writable
class UserSerializer(serializers.ModelSerializer):
    class Meta:
        model = User
        fields = "__all__"
# Fixed: explicit fields, sensitive ones read-only
class UserSerializer(serializers.ModelSerializer):
    class Meta:
        model = User
        fields = ["id", "display_name", "role", "plan"]
        read_only_fields = ["id", "role", "plan"]

Spring MVC binds to a DTO and keeps the entity out of the request:

// Risky: the entity has role and plan
@PatchMapping("/users/me") User update(@RequestBody User body) { ... }
// Fixed: a record with only editable fields
record ProfileUpdate(String displayName) {}
@PatchMapping("/users/me") User update(@RequestBody ProfileUpdate body, Principal p) { ... }

ASP.NET Core uses a view model, or [BindNever] on protected properties:

// Risky: binds every public property of User
public IActionResult Update(User user) { ... }
// Fixed: a DTO, plus BindNever as a second layer on the entity
public record ProfileUpdate(string DisplayName);
public IActionResult Update(ProfileUpdate input) { ... }
public class User { [BindNever] public string Role { get; set; } }

NestJS validates a DTO with class-validator and drops unknown fields:

// main.ts: strip unlisted fields and reject extras
app.useGlobalPipes(new ValidationPipe({ whitelist: true, forbidNonWhitelisted: true }));
// DTO
export class UpdateProfileDto { @IsString() displayName: string; }

Express with Mongoose copies picked fields, as OWASP shows with _.pick:

// Risky: User.findByIdAndUpdate(id, req.body)
// Fixed:
const update = _.pick(req.body, ["displayName", "avatarUrl"]);
await User.findByIdAndUpdate(req.user.id, update);

Laravel Eloquent uses $fillable:

class User extends Model {
    protected $fillable = ['display_name', 'avatar_url']; // allow-list
}

Go decodes JSON into a struct that has only the writable fields:

type ProfileUpdate struct {
    DisplayName string `json:"display_name"`
}
dec := json.NewDecoder(r.Body)
dec.DisallowUnknownFields() // returns an error on role, plan, tenant_id
var in ProfileUpdate
if err := dec.Decode(&in); err != nil { http.Error(w, "bad request", 400); return }

How do penetration testers detect and prove mass assignment?#

Proof is a change that persists and that a second session can read. A 200 response that echoes the field is not proof, because many APIs echo input without storing it. Our method requires a read-back, and controls run beside the test.

1. Create two test accounts, A and B, in the same tenant, and note A's role and plan.
2. Collect candidate fields from responses, specs, error messages and JavaScript bundles.
3. Run a control: send an unknown field name such as zz_test and a field the user may legitimately write. Record how the server treats each.
4. Add one candidate field per request on a test-owned record. Change one thing at a time.
5. Read back through GET as the same user, then as another session (account B or an admin test account) to see the effect from outside.
6. Check the effect: a changed role or plan must change what the account can do. State what the changed field allowed.
7. Restore the record and note this in the report.

Destructive proofs use only test-owned accounts and records, and testing needs written authorization.

Mass assignment testing checklist#

• List each create and update endpoint and compare the fields returned with the fields the client sends.
• Try one sensitive field at a time on a test record: role, owner_id, tenant_id, plan, price, verified.
• Test nested objects, arrays, GraphQL inputs and bulk or import endpoints.
• Run unknown-field and wrong-type controls before judging a result.
• Read back as the same user and as a second user or role.
• Compare PUT, PATCH and POST, because they often bind differently.
• Check that tenant and owner values come from the session, not from the body.
• Confirm that a fix returns 400 or ignores the field, and that legitimate edits still work.

When should you get a professional test?#

Get one when your API accepts writes on objects that carry roles, plans, prices or tenant IDs, or after you add endpoints that bind models in bulk. A tester needs accounts for each role and a second tenant, so cross-account effects can be read back. Our API penetration testing covers mass assignment and IDOR in scope, and the JWT guide covers the token side of role claims. Testing starts only after written authorization from the system owner.