Mass Assignment
also called Auto-Binding, Over-Posting
A vulnerability where a request body is bound directly to an internal object, allowing a caller to set fields the API never intended to expose.
The convenience feature that causes it is framework auto-binding: the JSON body is mapped onto a model
object automatically. A user updating their profile sends {"name": "..."} — and an attacker sends
{"name": "...", "role": "admin", "accountBalance": 100000, "emailVerified": true}.
If the model contains those fields and binding is permissive, they are set. Nothing errors, and the audit trail shows a legitimate profile update.
The fixes:
Explicit allow-lists. Bind only named fields, never the whole object. Frameworks provide this and it must be used deliberately, because the default is usually permissive.
Separate request models from domain models. A dedicated DTO containing exactly the updatable fields makes the vulnerability structurally impossible rather than dependent on configuration — which is why this is the better answer.
Validate against the schema, rejecting unknown properties rather than ignoring them. Rejecting is strictly better: ignoring hides a client bug, and a mismatch between what the client sent and what the server did is worth surfacing.
The related risk in the same family is excessive data exposure in the other direction: returning the whole object and relying on the client to display only some of it. Both come from letting the internal model define the API contract, which is the underlying mistake.