Mass Assignment

Mass assignment (also called auto-binding or over-posting) is the anti-pattern of taking a request payload and binding all of its fields directly onto a domain or database object. Frameworks that map JSON or form data onto objects automatically make this easy — and dangerous, because the client can include fields the developer never intended to expose, such as isAdmin, role, accountId, or balance.

Why It Happens

Auto-binding is a major convenience: one line maps the whole request to a model, avoiding tedious field-by-field assignment. It works perfectly for the fields the form shows, so the risk stays invisible. Using the same class as both the API contract and the persistence model couples them, so every database field becomes silently settable. Developers assume clients will only send the fields the UI presents.

Why It Hurts

Attackers do not use your UI. By adding extra fields to a request — {"name": "x", "isAdmin": true} — they set properties that were meant to be server-controlled. This enables privilege escalation (granting themselves admin), tampering with ownership or pricing, bypassing workflow states, or corrupting audit fields like createdBy. Because binding is automatic, new model fields become exploitable the moment they are added, often without anyone noticing.

Warning Signs

• Controllers bind the entire request body onto an entity or model in one step.
• The same class serves as the API request type and the database entity.
• There is no explicit list of fields a given endpoint may set.
• Sensitive fields (roles, flags, foreign keys, money) live on the same object that is bound from input.

Better Alternatives

Bind input to explicit, purpose-built data transfer objects (DTOs) that contain only the fields a given operation is allowed to accept, then map those to the domain model deliberately. Use field allowlisting (strong parameters, @JsonIgnore/read-only annotations, schema-defined writable fields) so only intended properties are settable. Keep server-controlled fields off the input model entirely and set them in code from the authenticated context. Validate the DTO against a schema as an additional guard.

How to Refactor Out of It

1. Identify endpoints that bind request bodies directly to domain or persistence objects.
2. Introduce request DTOs exposing only the fields each operation should accept.
3. Map DTOs to domain models explicitly, setting sensitive fields from server context, never from input.
4. Apply allowlist annotations or framework features to block binding of protected fields.
5. Add tests that submit unexpected fields (e.g. isAdmin) and assert they are ignored.
6. Decouple API contracts from persistence models so future fields are not auto-exposed.