Quick answer: Mass assignment (over-posting, excessive data binding) is when an application automatically binds an incoming request body (usually JSON) to the fields of an object and, in doing so, also accepts fields the user should not be able to write. If a user adds "role": "admin" or "isActive": true to the request body while updating their profile and the server blindly binds every field, the user can make themselves an administrator or change a price, a balance or an account status. It is listed as its own item in the OWASP API Top 10. The fix is to restrict incoming fields with an allowlist, use a safe DTO/input schema, and treat sensitive fields (role, balance, id, createdAt) as read-only. A blacklist approach is unreliable.

Mass assignment is the shadow side of the convenience modern frameworks offer. The "bind incoming data to an object in one line" feature speeds developers up, but if you do not explicitly limit which fields can be written from the outside, an attacker writes directly into your internal state by adding extra fields to the request body. This guide explains why the flaw is so common, its most dangerous examples, how it is detected, and the lasting fix.

How the flaw works: the shadow of auto-binding

Many frameworks offer shortcuts that bind incoming JSON or form data directly to a model/object instance. The developer writes a single call like user.update(request.body) and the framework writes every key in the body to the matching field. The intent is "let the client update the fields it sent." But the client can send not just name and email but every field the object owns.

The typical flow goes like this. A profile update form normally sends only name, email, phone. The attacker intercepts the request and adds "role": "admin", "isAdmin": true, "emailVerified": true or "balance": 999999 to the body. If the server binds the whole body to the object, those fields are written too. The user never sees these fields in the interface; the flaw lies in the gap between what the interface shows and what the server accepts. That is why the flaw requires testing the API contract, not just the form.

The most dangerous examples

Added field Impact
role / isAdmin Privilege escalation, becoming an administrator
isActive / emailVerified Skipping an approval/verification step
balance / credit / points Inflating a balance or points
price / discount Changing an order price
userId / ownerId Binding a record to another user (combines with IDOR)
id Overwriting a record id, causing collisions
createdAt / status Manipulating business-logic state

Mass assignment often combines with other flaws. For example, being able to change the userId field overlaps with insecure direct object reference (IDOR). Changing a price field turns into a business-logic flaw. That is why, in API security testing, mass assignment is assessed together with authorization flaws, as we cover in our OWASP API Top 10 article.

How it is detected

Detection requires discovering the real set of fields the API accepts. The pentester first looks at a GET response of an object: if the response contains fields like role, balance, createdAt, they try whether the same fields are accepted on an update/create request too. The method is to intercept a legitimate request, add extra fields to the body, and check whether the response or a subsequent GET reflects that field.

Automated scanners usually miss this because they do not know which field is sensitive and what the expected business logic is. Reliable detection is done with a manual test that understands the API contract and the data model. The intercept-and-replay flow we describe in our Burp Suite guide is the core tool here. What matters is proving the added field was actually written; a 200 response alone is not enough.

The lasting fix: allowlist, DTO, read-only fields

The only reliable fix for mass assignment is to define explicitly which fields can be written from the outside:

  • Allowlist. Take only the permitted fields from the incoming body and ignore the rest. Saying "these fields can be updated" is always safer than "these fields cannot be updated," because when a new sensitive field is added and the blacklist is not updated, the flaw returns.
  • Input DTO / schema. Bind the incoming data not directly to the database model but to a separate input object (DTO) or schema (for example with a validation library) that contains only the permitted fields. Separating the model from the external contract is the most robust approach.
  • Read-only fields. Mark fields like id, role, balance, createdAt, ownerId as read-only or protected at the framework level; let these fields change only through server-side logic.
  • Separate the authorization step. Operations like a role change should go through a separate, authorized endpoint; never bind them to the same path as a general profile update.

This design is also connected to general security misconfiguration; we cover leaving defaults insecure in our security misconfiguration article.

The KAOS and DSET approach

At DSET we treat mass assignment as a standard item in API and web application tests, because its impact is often direct privilege escalation or financial manipulation. In our tests we derive the full field set of an object, inject sensitive fields into update and create endpoints, and verify the flaw not just as "accepted" but by proving the field was actually written and created an authorization/state change. Our KAOS tool flags automatic model-binding patterns and endpoints where sensitive fields that should be read-only can be updated, but it ties the final verdict to proven write behavior. To have your API tested against mass assignment and related authorization flaws, contact DSET and reach our team at Ankara Hacettepe Teknokent.

Frequently asked questions

Are mass assignment and IDOR the same thing? No, but they often appear together. IDOR (insecure direct object reference) is about accessing someone else's record; mass assignment is about writing fields that should not be in your request. When combined, you could, for example, bind a record to another user by adding ownerId to an update request. That is why both are assessed together under authorization testing.

Why is a blacklist (blocking sensitive fields) not enough? Because a blacklist requires maintenance and is easy to forget. If you block role and isAdmin today, a isSuperAdmin or accountTier field added tomorrow turns into a flaw because it is not on the list. An allowlist works the other way: only explicitly permitted fields are written, and every newly added field stays safe by default. This is the secure-default principle.

Does it happen in GraphQL and modern APIs too? Yes. GraphQL schemas that define input types too broadly or leave all object fields writable in mutations have the same flaw. We cover GraphQL-specific authorization and input topics in our GraphQL API security article. The fix is the same: define only genuinely writable fields in input types.

Sources

  • OWASP API Security Top 10, Broken Object Property Level Authorization and mass assignment items.
  • OWASP Web Security Testing Guide, mass assignment test section.
  • CWE-915 (improperly controlled modification of dynamically-determined object attributes).
  • DSET blog: API security OWASP API Top 10 and security misconfiguration.