What Is a Mass Assignment Vulnerability? How Attackers Escalate Privileges Through Your API

What Is Mass Assignment

Mass assignment is a vulnerability that arises from a common developer convenience feature. Many web frameworks — Ruby on Rails, Laravel, Django, Spring, and others — allow developers to create or update a database record by passing a hash or object directly to the model, without explicitly specifying which fields should be written.

This is convenient. Instead of writing:

```javascript user.firstName = body.firstName; user.lastName = body.lastName; user.email = body.email; ```

The developer writes:

```javascript user.update(body); ```

The framework maps every field in the request body to the corresponding field in the database model. When it works as intended, this saves a significant amount of repetitive code.

The vulnerability arises when the database model contains fields that should not be user-settable — an `isAdmin` flag, a `role` field, an account `balance`, a `verified` status, or a `subscriptionTier` — and the mass assignment operation does not explicitly exclude them. An attacker who discovers the API endpoint can include these extra fields in their request, and the framework will write them to the database.

A Concrete Example

Consider a user registration endpoint that accepts a JSON body:

```json { "firstName": "John", "lastName": "Smith", "email": "john@example.com", "password": "mypassword" } ```

The server creates a user record from this body using mass assignment. The User model in the database also has an `isAdmin` field, defaulting to `false`.

An attacker registers and simply adds the extra field:

```json { "firstName": "John", "lastName": "Smith", "email": "john@example.com", "password": "mypassword", "isAdmin": true } ```

If mass assignment is unprotected, the `isAdmin: true` field is written to the database along with the legitimate fields. The attacker now has an administrator account.

The same attack applies to profile update endpoints. If a user can update their own profile, and the update endpoint uses mass assignment without a whitelist, the attacker can include any writable field in the update — including ones that should only be set by the application itself.

Why This Appears in Real Applications

Mass assignment vulnerabilities are particularly common in API-first applications and in codebases that have grown quickly. The pattern of "pass the request body to the model" is taught in framework tutorials and is the default in many scaffolding generators. Developers who are focused on building features quickly may not consider which fields in the model are sensitive until a security review surfaces the issue.

The vulnerability is also easy to miss in code review. Looking at the line `user.update(req.body)`, the immediate question is whether the request is authenticated, not which fields in `req.body` should not be settable.

Where Mass Assignment Occurs Beyond Admin Flags

The admin flag example is illustrative, but mass assignment vulnerabilities cover a wider range of sensitive fields:

**Account balance or credits** — An e-commerce platform or SaaS product that stores a credit balance in the user model. An attacker updates their profile and sets `credits: 9999`.

**Subscription tier or plan** — A SaaS application where the user's plan is stored alongside their profile. An attacker upgrades themselves to the enterprise tier without paying.

**Verified or confirmed status** — An application that requires email verification before certain features are available. An attacker sets `emailVerified: true` without clicking the verification link.

**Role in multi-tenant systems** — A B2B SaaS where users belong to an organisation and have a role within it. An attacker updates their own record to set `role: "owner"` on another organisation's account.

**Internal metadata fields** — Created timestamps, internal scoring, fraud flags, or soft-delete markers that the application uses internally. Manipulating these can bypass fraud checks, restore deleted accounts, or corrupt application logic.

Prevention

Explicit allowlists (strong parameters / fillable fields)

The correct fix is to explicitly define which fields are settable through mass assignment. In Laravel, this is the `$fillable` array on the model. In Rails, it is strong parameters in the controller. In Django REST Framework, it is the `fields` list on the serializer.

Only fields that users should be able to set are included in the allowlist. All other fields — regardless of whether they appear in the request — are ignored.

Request DTOs and explicit mapping

An alternative to framework-level allowlisting is using a Data Transfer Object (DTO) — a separate class that represents the data accepted from the user. The DTO only contains the fields the user is permitted to send. The application code explicitly maps from the DTO to the model, making it clear exactly which fields are being written.

This approach is more verbose but makes the allowed fields explicit in the code and easier to review.

Strip sensitive fields before processing

For endpoints where most fields are user-settable but a few are not, delete the sensitive fields from the request body before passing it to the mass assignment operation:

```javascript delete req.body.isAdmin; delete req.body.role; user.update(req.body); ```

This is a less robust approach than allowlisting — it requires remembering to add every new sensitive field to the delete list — but it is a valid mitigation for specific high-risk fields in an existing codebase.

What Yrzo AI Tests

Mass assignment vulnerabilities require authenticated testing — the vulnerability exists in API endpoints that users can reach after logging in. A Yrzo AI [Professional scan (£399)](/checkout/standard) includes:

- Authenticated API endpoint enumeration - Mass assignment probing on user creation and update endpoints - Privilege escalation checks — specifically testing whether role or admin fields can be set through API requests - [IDOR testing](/blog/what-is-idor-vulnerability) on user and account management endpoints

The Advanced scan (£799) adds multi-role testing — scanning as a standard user and verifying whether requests that modify elevated fields are rejected correctly at the API level.

Related reading: [What Is IDOR Vulnerability?](/blog/what-is-idor-vulnerability) · [What Is Broken Access Control?](/blog/what-is-broken-access-control) · [How to Secure an API](/blog/how-to-secure-an-api-uk)