Mass Assignment in APIs: How to Find Privilege Escalation Bugs

Mass assignment (also called over-posting) happens when an API binds request JSON to a model and accidentally accepts fields the client should never control — role, isAdmin, balance, verified, price, or ownerId.

OWASP groups related failures under broken object property level authorization. For hunters, the method is simple: discover hidden writable properties and prove a security state change on accounts you own.

Where it appears

PATCH /api/me and profile update endpoints
Registration and onboarding payloads
Organization / team creation
Billing plan changes and coupon redemption
Import and bulk-update APIs
GraphQL mutations that accept large input objects

Compare the UI form to the actual JSON the client sends. Then compare that JSON to fields returned by GET responses or schema docs.

Testing method

Create two normal users.
Update a profile with an extra property guessed from responses: {"role":"admin"}, {"is_staff":true}, {"email_verified":true}.
Re-fetch the object and the session/permissions.
Try the same on object update endpoints with another user's ID only if IDOR is already in scope and you use test data.

Also try nested objects: {"user":{"role":"admin"}} and arrays of attributes. Frameworks differ in what they bind.

Strong vs weak findings

Strong: your user gains admin, bypasses verification, changes another tenant's owner, or sets a price to zero and completes a purchase.

Weak: the API stores a harmless unknown field that never affects authorization.

Triagers care about the security decision that changed, not merely that an extra key was accepted.

Chaining

Mass assignment pairs well with:

IDOR / BOLA on the same object
Hidden admin endpoints discovered in JS bundles
Feature-flag fields that unlock paid capabilities

Document each step with two accounts so ownership stays clear.

Report structure

Show original request, modified property, before/after GET responses, and the privileged action now possible. Recommend allowlists for writable fields, separate DTOs for input vs output, and server-side authorization on every sensitive property.

Defensive checklist

Bind only an allowlisted DTO for writes.
Never reuse database entities as request bodies.
Enforce property-level authorization in the service layer.
Log unexpected fields in staging to catch client/server drift.
Add tests that assert role and payment fields are immutable from clients.

Mass assignment remains a top search intent topic because APIs expose business properties directly. If the client can name a field, assume someone will try to set it.

Original Bugflare guide informed by OWASP API Security — broken object property level authorization.

Mass Assignment in APIs: How to Find Privilege Escalation Bugs

Where it appears

PATCH /api/me and profile update endpoints

Registration and onboarding payloads

Organization / team creation

Billing plan changes and coupon redemption

Import and bulk-update APIs

GraphQL mutations that accept large input objects

Compare the UI form to the actual JSON the client sends. Then compare that JSON to fields returned by GET responses or schema docs.

Testing method

Create two normal users.

Update a profile with an extra property guessed from responses: {"role":"admin"}, {"is_staff":true}, {"email_verified":true}.

Re-fetch the object and the session/permissions.

Try the same on object update endpoints with another user's ID only if IDOR is already in scope and you use test data.

Also try nested objects: {"user":{"role":"admin"}} and arrays of attributes. Frameworks differ in what they bind.

Strong vs weak findings

Strong: your user gains admin, bypasses verification, changes another tenant's owner, or sets a price to zero and completes a purchase.

Weak: the API stores a harmless unknown field that never affects authorization.

Triagers care about the security decision that changed, not merely that an extra key was accepted.

Defensive checklist

Bind only an allowlisted DTO for writes.

Never reuse database entities as request bodies.

Enforce property-level authorization in the service layer.

Log unexpected fields in staging to catch client/server drift.

Add tests that assert role and payment fields are immutable from clients.

Mass assignment remains a top search intent topic because APIs expose business properties directly. If the client can name a field, assume someone will try to set it.

Original Bugflare guide informed by OWASP API Security — broken object property level authorization.

Mass Assignment in APIs: How to Find Privilege Escalation Bugs