Mass Assignment

Mass Assignment (parameter binding) abuses the fact that many web frameworks automatically dump every field of a request onto the attributes of a model object. If the developer trusts that binding and does not declare a whitelist of editable fields, we can add a parameter that does not appear in the form (say role, is_admin, verified) and the framework will write it into the object without asking. The typical outcome is privilege escalation: register as a customer and come out as an administrator.

The attack has two phases. First you observe the object's real shape by intercepting a legitimate request (sign-up or profile edit) with Burp: the server's response often reveals attributes the form never shows, such as role. Then you resend the request adding the sensitive field with the value you want:

POST /api/register HTTP/1.1
Content-Type: application/json

{"email":"a@a.com","password":"Passw0rd!","role":"admin"}

When the field name shows up in no response, you discover it by logic or by dictionary: the usual conventions are isAdmin, is_admin, admin, role, privilege, user_type. Try them one by one (or with Intruder) and a 200 OK or a state change confirms the right name:

PATCH /users/2 HTTP/1.1
Content-Type: application/json

{"username":"guest","is_admin":true}

Requirements. The backend must perform mass binding with no whitelist (patterns like Rails' params.permit!, Model(**request.json) or a Node Object.assign(user, req.body)) and the target attribute must exist in the model and affect authorization. With no sensitive field to reach, mass binding is harmless.

How to detect it. In the application log the signature is a sign-up or update request that includes parameters absent from the official form (role, is_admin) from an unprivileged account, often preceded by several attempts with different field names (the dictionary sweep). On the model side, an audit that records changes to sensitive attributes exposes a user account marking itself as an administrator, something no legitimate flow does.

Defence. Never bind the request directly to the model: explicitly declare which fields are assignable (whitelist / strong parameters / DTO) and keep authorization attributes out of that set, managed only by server logic. Verify authorization on every operation; do not trust that the client only sends the form fields. It overlaps with the broken access control of IDOR.