Home / Knowledge hub / Mass assignment
Knowledge hub
Mass assignment
When the fields in a request get written straight onto a record.
What it means
Mass assignment is a framework convenience. Instead of copying each field by hand, the code takes whatever arrived in the request and applies it to the record in one step. It saves a great deal of typing and it does exactly what it is told.
The client writes the request. Somebody updating a profile can add a field the form never showed, such as role, is_admin or verified. If that field exists on the record, the update writes it too. OWASP's API Security project lists this as API6:2019.
Why it matters
An ordinary authenticated action becomes privilege escalation, using a feature every account already has. Nobody breaks in. The attacker is a normal customer sending a slightly longer version of a request your application invites them to send.
Code review misses it because the code looks clean. One tidy line updates the record and never names the dangerous field. The flaw lives in what the line does not say, which is how it survives review and shows up later as a serious finding.
How it shows up
Go through every endpoint that creates or updates something. Profile edits, registration, settings, address books, anything accepting a JSON body. Compare the fields your form sends with the fields the record holds, and treat the gap as attack surface.
OWASP's fix is a data transfer object, or an explicit allowlist of bindable fields, so adding a column later does not expose it by accident. Testing means taking a legitimate request, adding a field that should not be settable, and checking whether the stored record moved.
Questions people ask
Mass assignment, answered
Does my framework protect me by default?
Some do and many do not. Rails added strong parameters after a famous incident, and several modern frameworks still bind whatever arrives unless you tell them otherwise.
Check your own version rather than assuming. The behaviour also changes between major releases, which catches teams during upgrades.
Is sending is_admin true really all it takes?
Sometimes, yes. Open developer tools, intercept the profile update, add the field, send it. If the record has that column and the code binds blindly, the value lands.
Most applications are not quite that generous. The interesting fields are often subtler, such as an account status, a tenant id or a price.
Should I use a denylist of protected fields?
Only as a stopgap. A denylist protects the fields you remembered, and the next migration adds a column nobody adds to the list.
Name the fields the endpoint may write instead. New columns then stay unreachable until somebody decides otherwise.
Does it only affect REST APIs?
No. GraphQL mutations that take an input object have the same problem, and so do server-rendered forms that bind a model directly.
Anywhere a request body maps onto a stored object, ask which fields that mapping is allowed to touch.
How do I test for it?
Send a legitimate update, then send it again with an extra field you should not control. Read the record back afterwards rather than trusting the response.
Plenty of applications answer with a tidy 200 and a clean payload while the extra field quietly lands.
Related
Terms that sit next to this one
Privilege escalation
Gaining rights you were never given, sideways or upwards.
Input validation
Checking that what arrives is the shape and range you expected.
Allowlist
A list of what you permit, with everything else refused by default.
Broken access control
An application failing to enforce its own rules about who may do what.
API
The part of your application other software talks to, not a person.
Add a field, become an admin?
We send legitimate requests carrying fields your forms never offered, then report what the stored record did next, with the exact payload. Start with a $199 pilot on one application.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.