Mass Assignment

Why It Matters

Frameworks make development fast by automatically binding request data to objects, but that convenience becomes a vulnerability when the object holds fields the user should never control. A single hidden field, role set to admin, turns an ordinary signup into a takeover of the application itself.

Mass assignment is especially common in APIs and is one of the cleaner privilege escalation paths a tester can find, which is why it sits on the OWASP API Security Top 10. It is also known as autobinding or object injection and is catalogued as CWE-915.

How Frameworks Autobind

To save developers from writing one assignment per field, frameworks offer helpers that map an entire request body onto a model in a single call. When the model includes sensitive columns and the binding has no allow list, every column becomes writable from the request. The most famous example is the 2012 GitHub incident, where a researcher used mass assignment to add his public key to an organization he did not control. The same pattern exists in Rails, Laravel, Spring, ASP.NET, Django, and many Node.js ORMs.

How It Works

A registration endpoint accepts JSON and validates it well:

{ "username": "testuser", "email": "test@example.com", "password": "Test123!" }

The attacker adds a field the form never showed and, often, switches the content type so a looser parser handles it:

<user>
  <username>testuser</username>
  <password>Test123!</password>
  <role>admin</role>
</user>

If the server binds <role> straight onto the user model, the new account is created as an administrator. This combines two issues: a content type that bypasses validation and an autobinding that should never have accepted role from the client. It is a frequent result of parameter tampering during API testing.

How to Test for It

Capture a create or update request and compare the fields the UI sends against the object's likely properties. Add candidates such as role, isAdmin, is_admin, verified, approved, balance, user_id, and group, one at a time, and watch whether the response or a follow up request confirms the field was accepted. Read a GET of the same object first, because the fields it returns are strong hints about the writable properties. Then retry the request under each accepted content type, since validation often differs between JSON, XML, and form data.

Prevention

Bind from an explicit allow list of safe fields, never bind whole request objects, and keep a separate write model from your internal model. Reject unexpected fields, validate every content type to the same standard, and set sensitive properties such as role only in server side logic that the client cannot influence.