Many beginners forget Mass assignment in Bug Bounty programs .

Beginners often focus on vulnerabilities such as SQL injection, Broken Access Control, IDOR, and BOLA. While these are important, there is another vulnerability that can be easy to overlook: Mass Assignment.

What is Mass Assignment?

A Mass Assignment vulnerability occurs when an API automatically binds user-controlled input to a backend object or database model without properly restricting which fields the user is allowed to modify.

In simple terms, the application may allow you to change more than you were supposed to.

Why is it dangerous?

Mass Assignment can have serious consequences depending on which fields are exposed.

Privilege escalation — changing your account role or attempting to make yourself an administrator.
Unauthorised actions — modifying fields or data that should not be controlled by the user.
Business logic abuse — manipulating values such as prices, account types, permissions, or premium-feature flags.

A Simple Example

Imagine an application has a profile update endpoint:

POST /api/profile
Content-Type: application/json
{
  "name": "Manuel",
  "email": "manuel@example.com"
}

POST /api/profile
Content-Type: application/json
{
  "name": "Manuel",
  "email": "manuel@example.com"
}

The developer expects users to modify only:

name
email

However, the backend user object might contain additional fields:

{
  "name": "Manuel",
  "email": "manuel@example.com",
  "role": "user",
  "isAdmin": false
}

{
  "name": "Manuel",
  "email": "manuel@example.com",
  "role": "user",
  "isAdmin": false
}

If the backend blindly assigns every field received from the client, an attacker could test whether additional fields are accepted:

POST /api/profile
Content-Type: application/json
{
  "name": "Manuel",
  "email": "manuel@example.com",
  "isAdmin": true
}

POST /api/profile
Content-Type: application/json
{
  "name": "Manuel",
  "email": "manuel@example.com",
  "isAdmin": true
}

If the server processes isAdmin even though it was never intended to be controlled by the user, this could result in an unauthorised privilege change.

The important point is that the vulnerability is not simply the existence of an isAdmin field. The issue is that the server allows an untrusted client to modify a sensitive field that should have been protected.

How to Hunt for Mass Assignment

1. Understand the Object Structure

Start by thinking about what fields might exist behind the API.

Look for potentially sensitive properties such as:

role
isAdmin
userId
createdAt
balance
permissions
status
accountType

role
isAdmin
userId
createdAt
balance
permissions
status
accountType

These fields are not automatically vulnerable. They become interesting when the client can influence values that should be controlled exclusively by the server.

2. Test for Additional Fields

When testing an authorised application, inspect the requests sent by the frontend.

Then try adding fields that are not normally present in the request body.

For example:

{
  "name": "Manuel",
  "isAdmin": true
}

{
  "name": "Manuel",
  "isAdmin": true
}

You can also test other relevant properties based on the application's functionality.

The goal is to determine whether the API accepts and processes fields that the user should not be able to modify.

3. Don't Trust Frontend Restrictions

A common mistake when testing APIs is assuming that a field cannot be modified simply because the frontend does not provide an input for it.

Frontend restrictions are not security boundaries.

For example, if the web application prevents a user from editing a particular field, intercept the request with Burp Suite and inspect what the backend actually accepts.

Modify the request and send it directly to the API.

If the backend accepts a sensitive field that the frontend intentionally hides or restricts, investigate further.

Final Thoughts

Mass Assignment is easy to miss because the vulnerable parameter may not appear anywhere in the normal user interface.

As a bug hunter, don't only ask:

"What can I access?"

Also ask:

"What can I modify that I shouldn't be able to modify?"

That mindset can reveal vulnerabilities that traditional testing might overlook.

Contents