Mass Assignment
Mass assignment binds request fields straight into model properties, letting clients set privileged attributes — role, balance, owner_id — that the endpoint never intended to expose.
Definition
Mass assignment is the convenience pattern of populating an object from a bag of request keys. When the binding is unconstrained, client-chosen keys map to any settable property: role, isAdmin, price, tenantId. The result is privilege escalation through ordinary endpoints. The fix is field allowlists per endpoint — bind explicit DTOs, never the model.
Context and scope
Classic in ActiveRecord-style ORMs and JSON body binding. Combines with object-level authorization when clients control ownership fields.
Common misconceptions
- ORMs prevent it by default — many bind all columns by default; prevention is explicit permit or schema-per-endpoint
- Hiding fields from serialization fixes it — output filtering controls responses; input binding is the attack surface
- Only admin fields matter — ownership and billing fields are equally exploitable escalation vectors
Anti-patterns
- Constructing entities from the whole request body with strong parameters omitted
- Reusing one update DTO across user self-service and admin endpoints, leaking privileged fields into the public one
- Testing only the happy path and never asserting that submitted extra keys are ignored
Related concepts
Related examples
Authoritative source
https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html
What it is
Updating a model from a dictionary of request keys is ergonomic and dangerous. The client controls the keys, the model has many settable properties, and their intersection includes fields the business never meant to expose. GitHub 2012 was the canonical incident: a public key update endpoint accepted the admin flag.
How it works
Frameworks map JSON keys to setters or columns. Defense is inversion: each endpoint declares the exact fields it accepts — strong parameters, explicit DTOs, schema validation — and unknown keys are rejected or ignored, never merged. Ownership and tenancy fields derive from the authenticated principal, not the body.
When to audit
Every create and update handler, especially admin-adjacent flows sharing DTOs. Contract tests should submit poisoned extra keys and assert both the response and the persisted entity lack them.
Pitfalls
Nested objects and arrays smuggle fields one level deeper where allowlists are flatter. Separate DTOs for admin and self-service prevent drift; a shared DTO eventually accumulates the union of both. Audit logging should record rejected keys as a signal of probing.