Mass Assignment labs
Mass Assignment / Autobinding
What is Mass Assignment?
Mass Assignment happens when a framework automatically binds the request fields to an object/model without an allowlist. By adding parameters not exposed in the UI (role, isAdmin, price, ownerId) you escalate privileges, tamper prices or steal ownership of other people's resources.
Why practice Mass Assignment?
Autobinding in Rails, Spring, Laravel, Express and modern ORMs is convenient but dangerous: almost no API filters well which fields the user can touch. An update that accepts isAdmin is direct privilege escalation, and one that accepts price is fraud. Typical bounties: $1,000-$10,000 per endpoint.
What will you learn with the Mass Assignment labs?
You'll learn to inventory ALL of a model's fields (not just the form ones), add privileged parameters to your own update body, escalate to admin, tamper price and owner in creations/checkout, and evade top-level filters with JSON and nested notation.
Types of Mass Assignment we cover
- Privilege escalation
You add role/isAdmin/verified to your own update body and the ORM dumps it to the DB without an allowlist, elevating you to administrator.
- Price/amount tampering
You inject fields like price, amount, discount or balance into a checkout or order to underpay or grant yourself balance.
- Owner override
You put userId/ownerId/accountId in a creation or edit to create resources in someone else's name or seize theirs.
- Nested object injection
With nested JSON (user[role]=admin or {"profile":{"tier":"pro"}}) you reach fields that deep binding copies without filtering.
How do you find and exploit Mass Assignment?
A practical playbook — from recon to proof of concept.
- 1
Map the model and its fields
Watch a GET of the object (or the GraphQL schema / front-end JS) to inventory ALL its fields, including the ones the form doesn't show.
GET /api/users/me → {id, email, role, isAdmin, verified, balance} (role/isAdmin not editable in the UI) - 2
Add non-exposed parameters
Resend a legitimate update but include the privileged fields in the body. If the backend doesn't reject them, there's mass assignment.
PATCH /api/users/me {"name":"x","role":"admin","verified":true} - 3
Escalate to admin
Set role/isAdmin and reload your profile: if the role persists, you've escalated privileges vertically without touching any admin endpoint.
{"isAdmin":true} → GET /me returns isAdmin:true = role takeover - 4
Change owner or price
On creation or checkout, inject someone else's ownerId or a lower price/amount to steal resources or underpay.
POST /api/orders {"item":"x","price":0,"ownerId":"<another-user-id>"} - 5
Test nested binding
If the filter only checks top-level fields, evade it with nested notation in JSON or query string.
user[role]=admin · {"account":{"tier":"lifetime_pro_plus"}}
Loading labs...
View in full catalog →Frequently asked questions
What is Mass Assignment?
It's a vulnerability where the framework automatically assigns the request parameters to an object's attributes without an allowlist. By adding fields the interface doesn't expose (role, isAdmin, price, ownerId), the attacker modifies properties they shouldn't be able to touch.
How is Mass Assignment exploited?
You capture a legitimate update of your own user and add privileged fields to the body (for example {"isAdmin":true} or {"price":0}). If the backend autobinds without filtering, those values are saved, achieving privilege escalation, price fraud or seizure of other people's resources.
How do you find Mass Assignment in bug bounty?
Inventory every field of each object by looking at its GET, the GraphQL schema or the front-end JS, and identify the ones not in the form (role, verified, balance, ownerId). Resend updates adding them and check whether they persist; also try nested notation to bypass top-level filters.
How do you prevent Mass Assignment?
Use an explicit allowlist of assignable fields (strong parameters, DTOs, field picking), never dump req.body straight into the model, separate input objects from persistence objects, and validate sensitive fields (role, price, owner) on the server with dedicated logic.
Difference between Mass Assignment and IDOR?
IDOR is reaching OTHER people's objects by changing their identifier. Mass Assignment is modifying FIELDS you shouldn't on the object (yours or someone else's) because the binding accepts them without filtering. They often combine: an IDOR on another user's object plus a mass assignment of their role is a full takeover.
Other related categories
- hunters training
- 650
- labs from real reports
- 50
- completions
- 380
- in bounties practiced
- $200,000
hunters training
labs from real reports
completions
in bounties practiced
Practice Mass Assignment in real labs
Every Mass Assignment lab replicates a real bug bounty report that got paid. Create your free account, start with the Academy and move to the labs whenever you want.
No card · free Academy · cancel anytime