Mass Assignment is an API vulnerability that occurs when an application automatically binds user-supplied input directly to internal data objects or model properties without properly filtering which fields the user is actually allowed to set. As a result, an attacker can include additional, unexpected fields in a request to modify object properties they should not be able to control – potentially escalating privileges, altering sensitive attributes, or tampering with data. It appeared in the OWASP API Security Top 10 (as API6:2019) and was later consolidated, together with excessive data exposure, into “Broken Object Property Level Authorization,” which focuses on missing authorization at the level of individual object properties.
The vulnerability stems from a convenience feature common in many web frameworks: the ability to automatically map incoming request data (such as JSON fields) directly onto an object’s properties in one step, rather than assigning each field individually. This is efficient for developers, but dangerous if the application does not restrict which properties can be set from user input. If the object contains sensitive fields the user should not control – such as isAdmin, role, accountBalance, verified, or userId – and the framework blindly assigns whatever the request provides, an attacker who adds those fields to their request can overwrite them.
A classic example: a user-registration or profile-update endpoint expects fields like username and email, and maps the request body onto a user object. An attacker submits the normal fields plus an extra “role”: “admin” or “isAdmin”: true. If the application performs mass assignment without filtering, it sets that property, granting the attacker administrative privileges. Similar abuse can change ownership, adjust balances, bypass verification, or modify other users’ data.
The impact of mass assignment is privilege escalation, unauthorized data modification, and integrity violations – an attacker manipulating properties that should be off-limits. Because the malicious request is structurally valid and simply includes extra legitimate-looking fields, this vulnerability often evades tools that inspect requests for obvious maliciousness.
Preventing mass assignment requires explicitly controlling which fields user input may set. Recommended practices include using allowlists that specify exactly which properties are bindable from user input (and rejecting or ignoring everything else), avoiding blanket auto-binding of request data to internal models, using separate data-transfer objects that expose only the intended fields, enforcing property-level authorization so users can only set fields they are permitted to, and validating input against strict schemas. The core principle is that the server must decide which properties a user can modify, never trusting the client to send only appropriate fields.