Mass Assignment Lab: Add an Admin Flag the Form Never Showed

This article teaches mass assignment (autobinding/over-posting), a vulnerability where backends blindly copy all fields from a request into a data model without validation. The lab demonstrates how an attacker can add an 'is_admin' flag to a signup request that the form never exposes, gaining admin privileges because the server lacks a whitelist of permitted fields. This vulnerability remains common in real-world APIs and maps to OWASP's Broken Access Control category.

• Mass assignment copies unfiltered request fieldsThe vulnerability occurs when an application uses bulk-binding to map incoming JSON request fields directly into a database model without explicitly whitelisting which fields are allowed. In the lab, a signup endpoint accepts username, email, and password from the form, but the backend copies every key from the entire request body into the User record, including hidden sensitive fields like is_admin that were never intended to be user-controllable.
• UI form fields do not constrain backend acceptanceThe form visible to a user only displays certain fields (username, email, password), but nothing technically prevents an attacker from adding extra fields to the raw JSON request before submission. The server has no mechanism validating that incoming requests match the form's intended shape, so an attacker can inject is_admin: true into the JSON body and the backend will honor it without question.
• GitHub 2012 case demonstrated real-world impactResearcher Egor Homakov exploited a mass-assignment flaw in Ruby on Rails to add his public key to an organization he did not own, proving the vulnerability was not theoretical. This famous incident shows how the same class of attack—over-posting role, balance, or owner_id fields—persists across many APIs today and has led to its classification under OWASP's Broken Access Control (A01).
• Whitelisting prevents bulk-binding exploitsThe primary defense is to use explicit allowlists (implemented via strong parameters, data transfer objects, or similar mechanisms) that specify exactly which fields each endpoint may accept and set. Instead of blindly copying the entire request body, the server must validate against a whitelist before binding any data to the model, rejecting or ignoring any fields not on the approved list.
• Separate input models from database modelsA architectural defense is to maintain distinct models: one for accepting user input (which contains only safe, non-privileged fields) and one for the database (which includes all columns including sensitive ones like is_admin). This separation ensures privileged fields are structurally impossible to bind from a request, even if code logic fails.
• Read-only enforcement at data layer adds protectionMarking sensitive fields as read-only at the database or ORM layer prevents them from being set by any user input, creating a secondary safeguard. Even if an attacker adds is_admin to a request and the application fails to whitelist, the data layer itself refuses to modify read-only columns.
• Testing requires probing for hidden fieldsSecurity testing for mass assignment involves adding unexpected fields (is_admin, role, balance, owner_id, verified) to create and update requests to see if the server honors them. By deliberately sending fields the API never exposed or documented, testers can discover whether the backend lacks proper whitelisting.

Bottom line: Mass assignment is a critical vulnerability where servers blindly copy unvalidated request fields into models; prevent it by using explicit whitelists of allowed fields, separating input models from database models, and marking sensitive columns read-only. During API assessment, always test by injecting unexpected privileged fields into requests to identify whether the server honors them without authorization.