Mass Assignment
Also known as: Auto-binding vulnerability · Object injection (property level)
Mass assignment happens when a framework's convenience feature for binding a request body onto an internal object (auto-mapping JSON fields to model or entity properties) is applied without an explicit allowlist of which fields a client may set. An attacker adds extra fields to a request body - ones the UI never exposes - and the framework writes them onto the underlying object regardless, including fields like role, isAdmin, or accountBalance that were only ever meant to be set server-side.
- CWE
- CWE-915
How it works
- 1An endpoint accepts a JSON body and binds it directly onto a database model or internal object using a framework's auto-mapping feature.
- 2The endpoint's allowed fields are defined by what the legitimate client happens to send, not by an explicit server-side allowlist or denylist.
- 3The attacker inspects the model (from framework conventions, API docs, or client-side code) and adds a field the UI doesn't expose, such as "role": "admin".
- 4The framework binds every field present in the body, including the injected one, and the object is saved with the attacker-controlled value intact.
Example
PATCH /api/users/me HTTP/2
Content-Type: application/json
{ "name": "Jane Doe", "role": "admin" }
# The UI only exposes "name" - "role" is bound anyway by the framework's auto-mapperImpact
Mass assignment routinely leads to privilege escalation (setting your own admin flag), price or balance manipulation, and bypassing fields that should be immutable after creation - often with a single extra JSON key and no other exploitation required.
Remediation
- Use an explicit allowlist (DTO, view model, or serializer schema) for every writable endpoint - never bind request bodies directly onto internal or persistence models.
- Mark sensitive fields (role, isAdmin, balance, ownerId) as non-bindable at the framework level, not just absent from the frontend form.
- Review auto-mapping and ORM binding conventions (e.g. Rails strong parameters, Spring @ModelAttribute, ASP.NET model binding) for any endpoint that skips them.
- Test every writable endpoint by adding fields it doesn't officially document, not just the ones the client sends.
Detection & testing
Diff an object's full schema against what a given endpoint's UI exposes, then submit the extra fields on write requests to confirm the server rejects or ignores them rather than binding them.
Impactr tests for Mass Assignment the way an attacker would - investigating, chaining it with related flaws, and proving impact with a reproducible exploit before it reaches your report.
Test my app for Auto-binding vulnerabilityTools
Frequently asked questions
Is mass assignment the same as IDOR?
No - IDOR is about accessing objects you don't own by manipulating an identifier. Mass assignment is about setting fields on an object you're already allowed to write to, just fields you shouldn't be able to control. The two often chain together: mass-assign an ownerId to claim someone else's object.