An API endpoint binds the entire JSON body to the user model, so a user can send `"isAdmin": true`. What is this, and the fix?

The endpoint takes the whole incoming JSON object and maps each property straight onto the user model. A normal client sends name and email; an attacker adds "isAdmin": true and the framework dutifully sets it. This is mass assignment (also called over-posting or auto-binding), a form of broken object property level authorization.

The correct fix: server-side allow-list binding

Decide, server-side, exactly which fields a given request is permitted to set, and bind only those. Concretely:

• Use a DTO / view model / "strong parameters" that contains only the editable fields for this operation, and map from it — never bind the raw request straight onto the persistence model.
• Treat privileged attributes (isAdmin, role, balance, verified) as never-client-settable; they change only through dedicated, authorized flows.

An allow-list is the safe default because anything you forget defaults to not bound. A denylist of "forbidden" fields fails the moment someone adds a new sensitive column and doesn't update the list.

Why the distractors are wrong

• Hide the field in the frontend confuses the UI with the API. The attacker isn't using your form — they send a raw HTTP request with whatever JSON they want.
• Rename isAdmin is security by obscurity. Field names leak via API responses, source maps, docs, and error messages, and are quickly guessed or discovered.
• Add client-side validation runs in the attacker's browser, which they fully control; it's trivially bypassed with curl or an intercepting proxy.

What the interviewer is probing

Whether you recognize that trust must be enforced server-side at the binding layer, can name the DTO/strong-params pattern, and understand why allow-listing beats both UI tricks and denylists. The tell of a weak answer is fixing it anywhere the client can see — because the client is exactly who you can't trust.