Mass Assignment / Over-Posting: Setting isAdmin from the Request Body

Privilege Escalation & Post-Exploitation Level 2/5 ~3 min 2026-07-15

The challenge

This is the request the app sends when you save your profile. It posts the fields the form shows - but the body also carries an isAdmin flag the form never displays, and the server saves whatever it receives. Flip that flag, send it, and read the admin flag the response unlocks.

What you'll learn

Recognize mass assignment when a server binds client JSON directly onto a privileged model
Spot a sensitive field (isAdmin) carried in a request body that the UI never exposes
Tamper a boolean field in a captured request and replay it to escalate privileges
Read an API response to confirm an admin panel and privileged data were unlocked
Explain why authorization attributes must be set by server logic, not bound from input

Skills tested

HTTP request inspection and tampering with a proxy-style editorIdentifying mass assignment / over-posting flawsReading and interpreting JSON API responsesReasoning about which model fields are safe to bind from client input

Prerequisites

Basic understanding of HTTP requests, JSON bodies, and form submissions
Familiarity with the idea of an admin role versus a normal user

How it works

Mass assignment - also called over-posting or auto-binding - happens when a framework maps the fields of an incoming request body straight onto a domain object, and the developer never restricts which fields are allowed. The convenience feature that copies displayName from JSON onto the user record will just as happily copy isAdmin, role, balance, or emailVerified if the attacker adds them, because the binder does not know which fields are sensitive.

The tell here is that the request body carries a field the form never showed you. A normal profile form lets you edit a display name; it does not render an admin switch. But the underlying request is just JSON, fully editable, and the server binds the whole object. Setting isAdmin to true is not exploiting a parser bug - the value is a perfectly valid boolean. The flaw is that a privilege flag was ever reachable through user-controlled binding.

This is a form of privilege escalation and broken access control. The same pattern lets attackers verify their own email, grant themselves credit, or change another user's id, depending on which columns the model exposes. The robust defense is to bind only an explicit allow-list of user-editable fields and to set every authorization attribute from trusted server logic.

Common mistakes

Assuming the request can only contain the fields the form displayed, when the body is plain JSON you can add to or edit freely.
Trying injection payloads on the display name instead of noticing the boolean privilege flag sitting in the body.
Sending a non-boolean like 1 or yes and giving up when the server rejects it - the field is validated as a boolean, so the value must be true.
Treating this as a UI bug rather than the real flaw: the server should never bind a privilege field from the request at all.

How to defend against it

Bind only an explicit allow-list of fields a user is permitted to change, and set authorization attributes from server-side logic alone. The request body should never be able to write to a privilege column - if isAdmin arrives in the JSON, drop it rather than honoring it.

Use a server-side allow-list (or a dedicated input DTO) listing exactly the editable fields, such as displayName; ignore anything else in the body.
Never expose sensitive columns (isAdmin, role, balance, emailVerified) to the auto-binder; set them only through controlled, audited code paths.
Enforce a separate authorization check for role changes - granting admin must require an admin actor, not a self-service profile save.
Log and alert when a request attempts to set a privileged field, so over-posting attempts are visible.