From P4 to P1 — Day 9: Mass Assignment Vulnerabilities in Bug Bounty Hunting

Introduction

Imagine registering an account on a web application.

During registration, you are allowed to provide basic information such as:

First name
Last name
Email address
Password

However, while inspecting the application's API, you discover that the backend accepts additional parameters that are not visible in the registration form.

What happens if you include a parameter such as:

{
  "firstName": "Researcher",
  "lastName": "Test",
  "role": "admin"
}

{
  "firstName": "Researcher",
  "lastName": "Test",
  "role": "admin"
}

If the application blindly accepts and processes this additional property, it may allow a normal user to modify information that should only be controlled by administrators.

This is an example of a Mass Assignment vulnerability.

For bug bounty hunters, mass assignment is particularly interesting because a seemingly ordinary API request may expose weaknesses in how an application handles user-controlled properties.

In Day 7, we explored object-level authorization. In Day 8, we covered function-level authorization. Today, we'll investigate another important API security weakness.

1. What is Mass Assignment?

Mass Assignment occurs when an application automatically maps user-supplied request parameters to internal object properties without properly restricting which properties the user is allowed to modify.

Developers sometimes use frameworks or object-relational mapping libraries that simplify database operations by automatically assigning incoming request data to application objects.

The problem occurs when sensitive properties are included in that automatic assignment.

For example, an application may expect:

{
  "name": "Divya",
  "email": "divya@example.com"
}

{
  "name": "Divya",
  "email": "divya@example.com"
}

But the backend may also accept properties such as:

{
  "name": "Divya",
  "email": "divya@example.com",
  "role": "admin",
  "isVerified": true
}

{
  "name": "Divya",
  "email": "divya@example.com",
  "role": "admin",
  "isVerified": true
}

If these additional properties are accepted without proper authorization, an attacker may be able to modify sensitive account attributes.

The core issue is not accepting JSON. It is allowing users to control properties they should not be permitted to modify.

2. Why is Mass Assignment dangerous?

The impact depends on which properties can be modified and how the application uses them.

Some potentially sensitive properties include:

PropertyPotential security impactroleUnauthorized privilege escalationisAdminUnauthorized administrative privilegesisVerifiedBypassing account verificationaccountStatusUnauthorized account state changesownerIdOwnership manipulationorganizationIdPotential tenant isolation issuessubscriptionPlanUnauthorized subscription changes

These are illustrative examples. Their presence in an API does not automatically mean the application is vulnerable.

The researcher must establish whether the property is actually accepted, whether the user is unauthorized to modify it, and whether the change has a meaningful effect.

3. Where should bug hunters look for Mass Assignment?

During authorized application testing, inspect API operations that create or update application objects.

A. User registration

Registration endpoints may accept more properties than the frontend exposes.

Example:

POST /api/register
Content-Type: application/json

POST /api/register
Content-Type: application/json

Review whether the backend accepts unexpected account properties.

B. Profile update endpoints

Applications commonly allow users to update their profiles.

Example:

PATCH /api/profile
Content-Type: application/json

PATCH /api/profile
Content-Type: application/json

Look at which properties are intended to be editable by the authenticated user.

C. Organization management

Multi-tenant applications may contain properties related to organization membership, ownership, and permissions.

Review whether ordinary users can modify properties that affect organizational access.

D. Subscription and billing functionality

Some applications store subscription-related attributes within user or organization objects.

Check whether these properties are properly restricted to authorized workflows.

E. Administrative account management

Review how applications process role changes, account activation, and other privileged updates.

The goal is to identify differences between user-editable properties and administrator-controlled properties.

4. How to test Mass Assignment manually

Only test applications you own or have explicit authorization to assess.

Use test accounts and disposable resources wherever possible.

Step 1: Identify an API endpoint

Start by observing normal application functionality.

For example, update your own profile and capture the request using Burp Suite or browser developer tools.

Example:

PATCH /api/profile
Host: example.com
Content-Type: application/json
Authorization: Bearer TEST_USER_TOKEN

PATCH /api/profile
Host: example.com
Content-Type: application/json
Authorization: Bearer TEST_USER_TOKEN

Step 2: Understand the normal request

A typical profile update might look like:

{
  "name": "Researcher",
  "bio": "Security researcher"
}

{
  "name": "Researcher",
  "bio": "Security researcher"
}

Record the properties that the application normally allows you to update.

Step 3: Review additional properties

Based on the application's documented behavior and your authorized test environment, identify whether sensitive properties are exposed in API responses or documentation.

Examples include:

{
  "role": "user",
  "isAdmin": false,
  "isVerified": false
}

{
  "role": "user",
  "isAdmin": false,
  "isVerified": false
}

These values are clues for investigation, not proof that the properties are writable.

Step 4: Test a harmless property first

Use a disposable test account.

Add a harmless, non-sensitive property to the request and observe whether the application accepts, ignores, or rejects it.

Compare the response with the original request.

Step 5: Validate sensitive property handling safely

If the program explicitly permits testing role or account attributes, use a dedicated test environment or a test account with an approved recovery path.

Do not attempt to grant yourself real administrative privileges or modify production account permissions.

Verify whether the backend rejects unauthorized property changes.

Step 6: Inspect the result

Check:

HTTP response status
Response body
Updated account state
Whether the property was actually persisted
Whether the property affects application behavior

A 200 OK response does not automatically prove mass assignment. The application may simply ignore unknown fields.

The important distinction is between a parameter being accepted in a request and an unauthorized property actually being modified.

5. Mass Assignment vs. Broken Access Control

Mass Assignment and Broken Access Control are related, but they are not identical.

Mass Assignment:

The application automatically assigns user-controlled input to object properties without sufficiently restricting the fields.

Broken Access Control:

The application allows a user to perform an action or access information they should not be authorized to access.

For example:

A user submits role: admin and the backend persists it without authorization: potential mass assignment.
A user accesses an administrative endpoint without the required permissions: BFLA.
A user changes an object identifier and accesses another user's resource: BOLA.

These weaknesses can overlap. A mass assignment issue that allows a user to change their role may also result in privilege escalation.

6. Common Mass Assignment testing mistakes

Mistake 1: Assuming unknown parameters are vulnerable

An application may safely ignore unexpected properties.

Always verify whether the property is actually modified.

Mistake 2: Reporting every additional JSON field

Some APIs intentionally support flexible metadata or user-defined fields.

Determine whether the property is security-sensitive and whether the user is authorized to control it.

Mistake 3: Confusing read access with write access

Seeing role, isAdmin, or accountStatus in an API response does not prove that these properties can be modified.

Test the write behavior separately.

Mistake 4: Ignoring server-side authorization

Even if a property is accepted, the backend may validate the user's permissions before persisting the change.

Understand the complete request-processing workflow.

Mistake 5: Claiming privilege escalation without proof

A request containing "role": "admin" is not sufficient evidence.

You must establish that the application actually changes the account's privileges. Use only approved test environments and accounts.

Mistake 6: Testing against real users

Never modify another user's account attributes to demonstrate a vulnerability.

Use accounts and resources that you control.

7. How to write a professional Mass Assignment report

The following is a sample report for a confirmed mass assignment issue in an authorized test environment.

Title: Mass Assignment Vulnerability Allows Unauthorized Modification of User Account Properties

Description:

During the security assessment, the application was observed accepting user-controlled properties through its profile update API without correctly restricting sensitive account attributes.

The backend processed an unauthorized property modification that should have been restricted to privileged application workflows.

This behavior may allow users to modify protected account attributes, potentially affecting account permissions or application security.

Steps to Reproduce:

Create an authorized test account.
Access the profile update functionality.
Capture the normal API request.
Identify a sensitive property that should not be user-editable.
In an approved test environment, submit a controlled request containing the additional property.
Inspect the server response and persisted account state.
Confirm whether the unauthorized modification was successfully applied.

Expected Result:

The application should accept only explicitly permitted properties and reject or ignore unauthorized changes to sensitive account attributes.

Actual Result:

The application processes an unauthorized modification to a protected account property.

Impact:

Depending on the affected property, an attacker may be able to manipulate account attributes, bypass intended restrictions, or gain privileges beyond their assigned permissions.

Remediation:

Implement explicit allowlists of user-editable properties.
Avoid directly binding untrusted request bodies to database models.
Enforce property-level authorization on the server.
Separate user-controlled fields from administrator-controlled fields.
Validate and sanitize incoming request data.
Add automated tests for unauthorized property modifications.
Review create and update operations across all API endpoints.

OWASP Mapping:

OWASP API Security Top 10: API3:2023 — Broken Object Property Level Authorization.
CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes.

8. How developers can prevent Mass Assignment

Developers should explicitly define which properties a user is allowed to modify.

For example, a vulnerable approach might look like:

app.patch('/api/profile', async (req, res) => {
    await User.updateOne(
        { _id: req.user.id },
        { $set: req.body }
    );
    res.json({ message: 'Profile updated' });
});

app.patch('/api/profile', async (req, res) => {
    await User.updateOne(
        { _id: req.user.id },
        { $set: req.body }
    );
    res.json({ message: 'Profile updated' });
});

This simplified example passes the entire request body into a database update operation.

A safer approach is to select permitted fields:

app.patch('/api/profile', async (req, res) => {
    const allowedUpdates = {
        name: req.body.name,
        bio: req.body.bio
    };
    await User.updateOne(
        { _id: req.user.id },
        { $set: allowedUpdates }
    );
    res.json({ message: 'Profile updated' });
});

app.patch('/api/profile', async (req, res) => {
    const allowedUpdates = {
        name: req.body.name,
        bio: req.body.bio
    };
    await User.updateOne(
        { _id: req.user.id },
        { $set: allowedUpdates }
    );
    res.json({ message: 'Profile updated' });
});

This example demonstrates an allowlist approach. A production implementation should also validate field types, handle omitted values correctly, and enforce authorization.

Additional recommendations:

Use allowlists for writable properties.
Validate request schemas.
Separate administrative and user-editable fields.
Enforce property-level authorization.
Avoid blindly assigning request bodies to database objects.
Test unexpected parameters during API security assessments.

9. Day 9 Mass Assignment validation checklist

Before submitting a finding, verify:

The endpoint is within the authorized scope.
The normal request structure is understood.
The sensitive property is identified
The property should not be editable by the tested user.
The backend actually processes the unauthorized modification.
The persisted result has been verified.
The security impact is demonstrated accurately.
Testing uses controlled accounts and resources.
Sensitive information is redacted.
Remediation addresses the underlying property authorization issue.

Final Thoughts

Mass Assignment is a reminder that API security is not just about validating which endpoints users can access. It is also about validating which properties they are allowed to control.

A user may be authorized to update their name and biography but should not automatically be allowed to modify their role, account status, or organizational permissions.

As bug hunters, we need to look beyond the visible frontend and understand how the backend processes user-controlled data.

Remember: An API accepting additional parameters is not automatically vulnerable. The real issue is whether an unauthorized user can modify protected properties.

This is Day 9 of From P4 to P1: The Bug Hunter's Journey.

We're continuing to build stronger API testing skills, moving from identifying authorization weaknesses to understanding how applications handle sensitive data and account properties.

Coming tomorrow — Day 10: Server-Side Request Forgery (SSRF). Can an application be tricked into making requests to internal or unintended destinations?

Follow along for the next part of the series. :)

Contents

Introduction

1. What is Mass Assignment?

2. Why is Mass Assignment dangerous?

3. Where should bug hunters look for Mass Assignment?

A. User registration

B. Profile update endpoints

C. Organization management

D. Subscription and billing functionality

E. Administrative account management

4. How to test Mass Assignment manually

Step 1: Identify an API endpoint

Step 2: Understand the normal request

Step 3: Review additional properties

Step 4: Test a harmless property first

Step 5: Validate sensitive property handling safely

Step 6: Inspect the result

5. Mass Assignment vs. Broken Access Control

6. Common Mass Assignment testing mistakes

Mistake 1: Assuming unknown parameters are vulnerable

Mistake 2: Reporting every additional JSON field

Mistake 3: Confusing read access with write access

Mistake 4: Ignoring server-side authorization

Mistake 5: Claiming privilege escalation without proof

Mistake 6: Testing against real users

7. How to write a professional Mass Assignment report

8. How developers can prevent Mass Assignment

9. Day 9 Mass Assignment validation checklist

Final Thoughts