Mass assignment is the write-side counterpart to excessive data exposure: instead of an API returning too much, it accepts too much. If your backend takes a request body and binds all of its fields straight onto a data object, a client can include fields it was never meant to set, a role, a verified flag, another user's identifier, and the server dutifully applies them. The app's form only shows a couple of editable fields, but the API accepts whatever the request contains. Here is what mass assignment is, how it leads to privilege escalation, and how to prevent it.
Short answer
Mass assignment is when an API binds client-provided input directly to an object's properties without filtering, so a client can set fields it should not, such as a role, a verified flag, a balance, or an owner identifier, by including them in the request. Per OWASP's API security guidance, the fix is to allow-list the fields a client may set per endpoint, rather than mapping the whole request onto your data model, and to never trust client-supplied values for security-relevant attributes. The app's form showing only a few fields does not protect you, because an attacker sends the request directly with extra fields. Decide on the server which properties a request can change.
What you should know
- Mass assignment binds input to object fields: without filtering what is allowed.
- Clients can set fields they should not: roles, flags, ownership, and more.
- It can escalate privileges: by setting an attribute that grants access.
- The app's form does not protect it: the attacker sends the request directly.
- Allow-list settable fields: per endpoint, on the server.
What is mass assignment?
It is letting client input set object properties wholesale. A convenient pattern in many frameworks is to take the request body and map it directly onto a model object, creating or updating all the fields present. That is fine when every field in the model is one the client should be able to set, and a vulnerability when some are not. If your user model has fields like role, verified status, or account ownership, and your update endpoint binds the request body straight to that model, a client can include those fields in the request and set them, even though the app's interface only exposes a name and avatar. The server applied them because it bound everything it received. The flaw is trusting the shape of the request to match what the client is allowed to change, when an attacker controls the request and can add any field.
How does mass assignment lead to privilege escalation?
By letting a client set an attribute that grants access or changes protected state. The table shows the pattern.
| Client sets | Consequence |
|---|---|
| role or isAdmin | Privilege escalation to higher access |
| verified or approved flag | Bypassing a verification or approval gate |
| account or owner ID | Reassigning or accessing another user's resource |
| balance or credit | Tampering with a value that should be server-controlled |
| internal status fields | Changing state the client should not control |
The classic case is setting a role or admin flag through an endpoint that was only meant to update a profile, escalating the account's privileges because the field was bound from the request. The same mechanism lets a client flip a verification flag, change ownership, or alter a value like a balance that should only ever be set by the server. In each case, the attribute should have been off-limits to client input, and mass assignment made it writable.
How do you prevent it?
Allow-list the fields a request may set, decided on the server. Rather than binding the whole request body to your data model, explicitly accept only the properties the client is permitted to change for that endpoint, often through an input model or data transfer object that contains just those fields, and ignore or reject anything else. Never let a security-relevant attribute, a role, a flag, an owner identifier, a balance, be set from client input; those are server-controlled, set by your logic based on authorization, not by the request. Validate the input you do accept, and combine this with object-level authorization so the client can only modify objects it owns. The principle mirrors the read side: just as you return only the fields a client should see, you accept only the fields a client should set, and you decide both on the server.
What to watch out for
The first trap is binding the request body directly to a data model, which lets a client set any field on it; allow-list the settable fields instead. The second is assuming the app's form limits what can be sent, when an attacker sends the request directly with extra fields. The third is letting a role, flag, or ownership field be writable from input. Mass assignment is a server-side flaw, so it is fixed and tested on your backend, but a pre-submission scan such as PTKD.com (https://ptkd.com) reads your app against OWASP MASVS and surfaces the API endpoints your app calls, a useful inventory of the write endpoints to review for mass assignment. The input handling lives on your server.
What to take away
- Mass assignment is an API binding client input directly to object properties without filtering, so a client can set fields it should not, like a role or a flag.
- It can escalate privileges or tamper with protected state by setting an attribute that grants access or changes server-controlled data.
- The app's form does not protect you, since an attacker sends the request directly; allow-list the settable fields per endpoint on the server and never trust client input for security-relevant attributes.
- Use a pre-submission scan such as PTKD.com to inventory the write endpoints your app calls, then review them for mass assignment on the server.
