What Are Mass Assignment Vulnerabilities?
Mass assignment (also called auto-binding or over-posting) lets an attacker set object fields they were never meant to control, simply by adding those fields to a request. It arises from a convenience feature — frameworks that automatically map request parameters onto objects — and turns that convenience into privilege escalation or data tampering when the mapping is too trusting.
How does mass assignment happen?#
A framework binds an incoming request body directly to a model:
Intended update: { "name": "Alex", "bio": "Hello" }
Attacker sends: { "name": "Alex", "bio": "Hello", "isAdmin": true }
Auto-bound object now has isAdmin = trueThe developer wrote code to update a profile’s name and bio; the framework helpfully bound
every field present, including isAdmin or accountBalance. Nothing validated which fields the
user was allowed to set — the authorization gap
again, at the field level.
How do you prevent it?#
Define the safe shape of input explicitly rather than trusting the request:
| Approach | How it helps |
|---|---|
| Field allowlist / strong parameters | Bind only named, permitted fields |
| DTOs / view models | Map to a dedicated input type, not the DB model |
| Explicit assignment | Set each field by hand from validated input |
| Mark fields non-bindable | Framework-level protection for sensitive attributes |
Mass assignment is a field-level form of broken access control, especially common in REST APIs. More at the Web Security hub.
Frequently asked questions#
What is a mass assignment vulnerability?
Mass assignment happens when a framework automatically binds request parameters to object fields, and an attacker includes fields they should not control. Adding "isAdmin": true or "balance": 999999 to a profile-update request can set privileged fields the developer never intended to expose, leading to privilege escalation or tampering.
How do you prevent mass assignment?
Use an explicit allowlist of the fields a given request may set, binding only those. Never bind whole request bodies straight onto database models. Many frameworks provide strong-parameter or DTO patterns for exactly this — define the safe shape of input rather than trusting whatever fields arrive.