Mass Assignment: The Field the UI Never Shows You

Table of contents

👋 Introduction

Hey everyone!

Last week we rewrote the stack with ROP. This week we climb back up to the API, where the bug is not memory corruption. It’s misplaced trust.

Mass assignment is the vulnerability that hides in the gap between the form the user sees and the object the server saves. The signup form asks for a username and a password. The server takes your entire request body and writes every field it finds onto the user model. So you add one field the form never showed you, role, and the server makes you an admin. In 2012 this exact bug let a researcher add his SSH key to the Rails organization on GitHub and gain commit access to the framework itself.

This week: how frameworks auto-bind you into a hole, the field that turns a profile update into admin, hunting parameters that aren’t in the UI, business logic you can rewrite for free, and the twin technique of HTTP Parameter Pollution.

Let’s get into it 👇

🎁 The Field the UI Never Shows You

Start with why this bug exists at all. To save you typing, web frameworks map an incoming request body straight onto an object or database model. You POST {"username":"ruben","password":"x"} and the framework calls something like User.update(request.body), binding every key to a matching field automatically.

The problem is the framework binds every key, not just the ones the form displayed. If the model has a role column and your request includes a role key, it gets written. The developer only meant to accept username and password, but they never said so out loud.

// The form sends this
{ "username": "ruben", "email": "[email protected]" }

// You send this instead
{ "username": "ruben", "email": "[email protected]", "role": "admin", "is_verified": true }

Every major framework ships a guard, and every guard is opt-in or easy to disable. Rails Strong Parameters wants an explicit allow-list, Laravel has $fillable, Django ModelForm has fields, .NET warns about over-posting. Express ships nothing, which is exactly why Node APIs leak here constantly. The realization to hold onto: the vulnerability is not a bad line of code, it’s a missing one.

👑 Turning a Profile Update Into Admin

The attack you want is privilege escalation, and mass assignment hands it to you through the most boring endpoint on the site. Any request that writes to a user object, profile update, settings, registration, is a candidate.

You look at the user model for a field the UI doesn’t expose. is_admin, role, verified, account_balance, user_id. Then you add it to a request the app already accepts and watch whether the server writes it.

Nested keys widen the surface. Frameworks bind structured bodies too, so user[role] or a JSON object reaches fields a flat parameter never would, and that nesting is often where the guard forgets to look.

This is precisely what Egor Homakov did to GitHub in 2012. The public-key form ran update_attributes on the whole request body with no allow-list, so he added a hidden public_key[user_id] field pointing at the Rails organization. GitHub bound his SSH key to that org, handing him commit access to rails/rails. The Django docs still cite this incident as the reason to never use a deny-list. The insight that changes your recon: the most dangerous endpoint is rarely the flashy one, it’s the CRUD update nobody thought to lock down.

🔍 Hunting Hidden Parameters

You can’t inject a field you don’t know exists. The whole attack rests on discovering parameters the application accepts but never advertises, and that’s a problem you brute-force.

You throw a wordlist of likely field names at the endpoint and watch for a response that changes, a different status, a reflected value, an altered object. A parameter the app quietly accepts behaves differently from one it ignores.

# Arjun: discover parameters the endpoint accepts but never shows
arjun -u https://target.example/api/users/42 -m JSON

# Then confirm the interesting ones by hand in Burp Repeater

Arjun ships a dictionary of around 26,000 parameter names and speaks GET, POST, JSON, and XML. Inside Burp, Param Miner does the same for hidden and unlinked parameters with binary-search guessing.

Discovery only tells you a field is accepted, not that it’s exploitable, so you confirm each candidate by hand. Send the write request twice in Repeater, once clean and once with the injected field, and diff the object the API returns.

PATCH /api/users/42 HTTP/1.1
Content-Type: application/json

{ "email": "[email protected]", "role": "admin" }

If role comes back reflected as admin in the response, or a follow-up read shows the elevated value, the field bound. The mindset shift: the attack surface of an API is not what the docs list, it’s every field the binder will silently accept, and those two sets are almost never equal.

💸 Business Logic for Free

Privilege escalation is the headline, but mass assignment quietly rewrites business logic too. Any field that governs money, state, or ownership is a target, not just the admin flag.

Picture a shop API where returning an item flips its status and triggers a refund. If the order object binds a status field, you set it to returned on an item you never shipped back, and the refund fires. Cobalt documented exactly this on OWASP crAPI, marking a purchased item as returned to manufacture a fraudulent refund. The vulnerable code did nothing exotic, it saved the whole request body onto the order and trusted every key in it.

// A "change quantity" request that also flips a field it shouldn't
{ "order_id": 1337, "quantity": 1, "status": "returned", "refunded": true }

OWASP tracks this under API3:2023 Broken Object Property Level Authorization, the 2023 category that folded classic mass assignment into a broader property-level authorization risk. The lesson: stop scanning only for is_admin. Every writable property that touches value is an escalation waiting for an allow-list nobody wrote.

🎭 HTTP Parameter Pollution

Mass assignment abuses fields the server didn’t expect. HTTP Parameter Pollution abuses the same field sent twice, and it exploits a gap no HTTP standard ever closed. When a request carries role=user&role=admin, nothing specifies which one wins.

Servers disagree, and that disagreement is the attack. Per OWASP WSTG, ASP.NET concatenates duplicates with commas, PHP and Apache take the last value, Java servlets take the first. When a WAF or validation layer inspects one occurrence and the app consumes a different one, you slip a payload straight through the gap.

POST /api/update HTTP/1.1
Content-Type: application/x-www-form-urlencoded

user_id=42&user_id=1&role=user&role=admin

The validator checks user_id=42, the backend reads user_id=1, and you just edited someone else’s account. This is the same input-trust failure behind the parameter pollution in Issue 43 on OAuth, applied to business logic instead of auth flows. The takeaway: whenever two components parse the same request, assume they parse it differently, and that difference is yours to weaponize.

🪤 The Deny-List Trap

The reason this bug survives modern frameworks is a choice developers get backwards. Given a guard, they reach for a deny-list, blocking the fields they know are dangerous, and every field they forget stays open.

An allow-list fails safe. A new column named is_superuser is invisible until someone explicitly permits it. A deny-list fails open. That same column is writable the moment it ships, because nobody added it to the blocklist. The gap between “what I blocked” and “what exists now” grows with every migration.

// Spring: the deny-list rots as the model grows
binder.setDisallowedFields("role", "isAdmin");   // miss one new field -> exposed
// The allow-list only ever grants what you name
binder.setAllowedFields("username", "email");    // new columns stay locked by default

The framework docs say this outright. Django’s ModelForm docs warn that the exclude deny-list “has led to serious exploits,” and Spring recommends setAllowedFields over the disallowed variant. When you audit a target, a deny-list in the binding code is a finding on its own, because the vulnerable field is whatever the developer added after they wrote it.

🎯 Key Takeaways

The mental model to carry out of this issue: the API’s real attack surface is every field the binder accepts, not every field the UI shows. Mass assignment lives in the silent gap between those two sets, and it is invisible from the front end. When you test any write endpoint, stop trusting the form, enumerate what the object could hold, and try to set the fields the interface hides.

Privilege escalation is one field away on the most boring endpoints. A profile update, a settings save, a registration, any of them can bind a role or is_admin you were never meant to touch. GitHub fell to this on a public-key form, so give the same suspicion to the CRUD endpoints everyone ignores, because that’s where the missing allow-list hides.

Do not stop at the admin flag. Property-level authorization is the broader bug, and any writable field that governs money, ownership, or state, status, balance, verified, user_id, is an escalation primitive. This is the object-property cousin of the prototype pollution from Issue 24, and the same instinct of injecting properties the code never validated carries straight across.

For the workflow: hitting a write endpoint, run Arjun or Param Miner first to surface hidden fields, then add likely escalation keys in Burp Repeater and diff the response. If the app filters or a WAF blocks you, send the parameter twice and let the parser mismatch carry it through. Reach for Arjun to find the fields and crAPI or VAmPI to practice the whole chain safely.

---

Practice:

• PortSwigger: Exploiting a mass assignment vulnerability - inject a hidden field to buy at a discount
• PortSwigger API testing learning path - mass assignment, hidden parameters, server-side parameter pollution
• OWASP crAPI - intentionally vulnerable API with a real mass-assignment chain
• VAmPI (erev0s) - vulnerable REST API with a mass-assignment toggle
• Arjun (s0md3v) - HTTP hidden-parameter discovery across GET, POST, JSON, XML
• Param Miner (PortSwigger) - Burp extension for hidden and unlinked parameters
• OWASP API3:2023 BOPLA - the property-level authorization risk that absorbed mass assignment
• OWASP WSTG: HTTP Parameter Pollution - server and client-side HPP testing

---

Thanks for reading, and happy hunting!

— Ruben

Other Issues

Stack Overflows to ROP: Beating NX, Canaries, ASLR

Previous Issue