Mass assignment happens when an app automatically binds every field in a request to an object's properties, so an attacker sets fields they shouldn't control by adding them to the request — e.g. slipping isAdmin: true or role: admin into a profile update. Modern frameworks make this easy with one-line request-to-model binding, which is why it's in the OWASP API Security Top 10. Impacts include privilege escalation, account takeover, financial manipulation and bypassing verification flags. It's a form of business-logic abuse scanners miss because the request is otherwise valid. Prevent it with an allow-list of settable fields per endpoint — never bind untrusted input straight to your objects.
// 01 What mass assignment is
Consider a "update my profile" endpoint. It expects name and email. Behind it, the developer used a convenient framework feature that binds the whole request body to the user object in one line. Now an attacker sends the normal fields plus an extra one the interface never offered — {"name": "...", "email": "...", "role": "admin"}. If nothing restricts which fields can be written, the framework dutifully sets role to admin. The attacker just escalated their own privileges by typing an extra key into a valid request. That's mass assignment: the application trusts the client to decide which properties get written, and the client abuses that trust.
// 02 Why modern frameworks make it easy
Every popular web framework offers a one-liner to bind a request onto a model — it's genuinely productive, and that's the point. But convenience and security pull in opposite directions here. Unless the developer explicitly restricts the fields, the framework writes whatever it receives, including sensitive properties: role, isAdmin, isVerified, account balance, owner_id and other foreign keys. The risk is highest in APIs that accept JSON and map it straight onto database models — exactly the modern pattern — which is why mass assignment (sometimes "excessive data exposure"'s twin) sits in the OWASP API Security Top 10.
// 03 What an attacker gains
| Extra field set | Impact |
|---|---|
isAdmin / role | Privilege escalation |
owner_id / foreign key | Account takeover / object reassignment |
balance / price / credit | Financial manipulation |
isVerified / isApproved | Bypassing verification or approval |
| Hidden internal fields | Tampering the UI never allowed |
In every case the request is otherwise legitimate and the response is a normal success — which is exactly why automated scanners miss it and a human tester finds it. It's close kin to the business-logic flaws that need someone reasoning about intent.
// 04 How testers find it
Finding mass assignment is methodical: a tester maps every write endpoint (create and update), works out what fields the underlying object really has — often by inspecting responses, documentation or the schema — then adds unexpected sensitive fields to requests and checks whether they take effect. Setting role, flipping isVerified, changing an owner ID: if the change persists, that's a confirmed finding. It's the kind of test that requires understanding the application's data model, which is why it lives firmly in manual testing.
// 05 How to prevent it
- Allow-list settable fields per endpoint (strong parameters, DTOs, explicit binding) — never bind the raw request to your object.
- Keep internal fields out of the input model entirely — roles, flags and foreign keys should be unreachable from a request.
- Enforce authorisation on privilege-changing fields so even a permitted field can't be abused across users.
- Separate read and write models so the shape you accept isn't the shape you store.
- Test every write endpoint with unexpected fields as part of API testing.
The durable fix is a mindset: the server, not the client, decides which fields may be written.
// 06 Frequently asked questions
What is a mass assignment vulnerability?
When an app automatically binds all fields in a request to an object's properties, letting an attacker set fields they shouldn't control by adding them to the request — like slipping isAdmin or role into a profile update to grant themselves admin. It stems from trusting client input to decide which properties get written.
How does it happen in modern frameworks?
Frameworks offer one-line binding of a whole request body to a model. Without explicit field restrictions, they write any field the attacker includes, including sensitive ones (roles, flags, balances, foreign keys). It's especially common in APIs mapping JSON straight onto database models — hence its place in the OWASP API Security Top 10.
What can an attacker do with it?
Whatever the extra fields control: privilege escalation (isAdmin/role), account takeover (owner/foreign key), financial manipulation (balance/price), bypassing verification (isVerified/isApproved), and tampering with UI-hidden fields. The request looks valid, so scanners miss it.
How do you prevent it?
Never bind untrusted input directly to objects. Use an allow-list of settable fields per endpoint (strong parameters, DTOs, explicit binding), keep internal fields out of the input model, enforce authorisation on privilege-changing fields, and test every write endpoint with unexpected fields.
// 07 References
- OWASP — API Security Top 10 and the Mass Assignment cheat sheet.
- Related: BOLA in REST APIs, business logic vulnerabilities, and our API penetration testing.