OWASP API Security Top 10 API6:2019 Mass Assignment with Example

In the previous blog, we learned about the OWASP API Security Top 10 API5:2019 Broken Function Level Authorization with Example. In this blog, we will learn about the OWASP API Security Top 10 API6:2019 Mass Assignment, its impact, an example, and remediation.

What is Mass Assignment?

Today's modern application frameworks provide developers with many ways to automatically assign input from client API requests into code variables and internal objects; however, if an attacker is able to update or overwrite sensitive object properties that the developers never intended to expose.


There is an API endpoint to create a new user.

POST /api/new/user

"username": "test",
"password": "test",
"email": "test@test.com"

The above API request will map the client-submitted username, password, and email value to the internal code variable or internal object data.username, data.password, and data.email
But internally, there is number of variables that the developer never intended to expose to the client.



It is a mass assignment if the client sends a post request to update or overwrite sensitive object properties that the developers never intended to expose.

POST /api/new/user

"username": "test",
"password": "test",
"email": "test@test.com"
"isadmin": true,
"balance": "10000"

The above request also updates or overwrites the Data.isadmin and Data.balance variables. 


If an attacker can exploit mass assignment vulnerability in the application, then the attacker can gain elevated privileges, tamper with data, or bypass security mechanisms.

How to check if the API is vulnerable to mass assignment vulnerability?

Check weather applications automatically assign client parameter values into internal object properties/code variables without considering these properties' sensitivity and exposure level.
Read API documentation
Make a GET request to fetch the parameters and try to update or overwrite those parameters using POST/PUT/PATCH.

Types for Properties:

  1. Permission-related properties: set by admin or higher privileged user (e.g., user.is_admin, user.is_vip)
  2. Process-dependent properties: set by internal processes or functions automatically based on specific actions or conditions (e.g., data.current_balance, data.points_earn)
  3. Internal properties: set by application (e.g., post.publish_date, transaction.date)

Example of Mass Assignment 

I have one POST method-based API endpoint that is used to create a new user by taking normal details like username, password, and email.

Suppose we add an additional parameter named "admin" with a value of "true" to check whether the newly created user will be granted admin permissions. Or not.

To verify whether the second user is assigned with admin role or not, we will check to debug logs.

As we can see in the above image first user (test) is set with admin = false, and the second user (test_admin) is set with admin = true.


  • Avoid using functions that automatically assigning client input into code variables or internal objects.
  • Whitelist only those properties that the client should update.
  • Use built-in features to blacklist properties that clients should not access.

Sahil Gupta

Application Security | DevSecOps | Secure SDLC | Penetration Tester (Web and API) | CEHv10 | IBM Certified Cybersecurity Analyst Professional

Previous Post Next Post

Contact Form